Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Say goodbye to Workflow - Time to Go with the Flow

  • 1.  Say goodbye to Workflow - Time to Go with the Flow

    TOP CONTRIBUTOR
    Posted 8 days ago
    Maybe I just did not notice this message before.  But when I went to create a workflow in Dynamics 365 v9 today, I got this pop-up message:

    "We recommend using Microsoft Flow instead of background workflows.  Click Here to  start building Flows!"

    Another sign I need to get with the times and Go with the Flow.



    ------------------------------
    Patrick O'Donnell | VP - Business Development, the Americas
    mscrm-addons.com
    Patrick.ODonnell@mscrm-addons.com
    Atlanta GA
    770 781 8260 Cell
    ------------------------------


  • 2.  RE: Say goodbye to Workflow - Time to Go with the Flow

    TOP CONTRIBUTOR
    Posted 8 days ago
    Hi Patrick. Flow is ok, but I think it has a long way to go before it can be as easy to use as native (no additional charge) workflows. Flow is built on top of Azure LogicApps, however it islocked-down and you cannot make mods to the code. Also, flow is at least 6x more expensive than Azure LogicApps. I would expect a developer to be able to use Flow, but not an end-user. For example, on the For-Each loops, you have options to adjust the degree of parallel tasks, and it is important you understand how that works because I have seen cases where you get unpredictable results if not done correctly.

    As a developer, I like LogicApps because it lets me build codeless workflows that span multiple systems external to my CRM system which makes integration much easier than it has in the past. I am building Canvas apps that that depend on Flow, so I will use it, but sparingly. However, IMHO, this is another example of how MS is just pushing us into using features that build their Azure business and increase their revenue.

    ------------------------------
    If this answered your question, please click on the arrow button next to Reply Inline and choose 'Make Best Answer.'
    Thanks.
    Nelson Johnson, Solution Architect
    BroadPoint, Inc., Bethesda MD
    Link with me! https://www.linkedin.com/in/nelsonjohnson/
    ------------------------------



  • 3.  RE: Say goodbye to Workflow - Time to Go with the Flow

    GOLD CONTRIBUTOR
    Posted 5 days ago
    Check out this thread for more insights too:

    https://www.crmug.com/communities/community-home/digestviewer/viewthread?GroupId=1285&MessageKey=eb03f372-ce67-4b94-98a9-38ca7b3c3c36&CommunityKey=dc83c23b-ede0-4070-ae7a-dd90859148a6&tab=digestviewer&ReturnUrl=%2fcrmug%2fcommunities%2fcommunity-home%2fdigestviewer%3fcommunitykey%3ddc83c23b-ede0-4070-ae7a-dd90859148a6%26tab%3ddigestviewer

    ------------------------------
    Sissy Bottcher
    Business Process Innovation Specialist
    StudyPortals
    San Diego CA
    ------------------------------



  • 4.  RE: Say goodbye to Workflow - Time to Go with the Flow

    GOLD CONTRIBUTOR
    Posted 4 days ago
    Edited by Ryan Perry 4 days ago
    @Nelson Johnson,

    Can you elaborate more on the degree of parallelism?  We have a single flow implemented so far, which runs a weekly report.  A few hiccups we ran into and solutions we had to workaround follow. Would love to hear your thoughts on any of these where you might have insight. Others might benefit by knowing about these and potential workarounds as well.

    Couldn't find a way to create an excel file in sharepoint easily, given input query results. Instead, we use an existing master template, clear the file, re-populate it, and then save a copy of the file each week.

    No way to specify synchronous operation. It seems the add row to excel file steps are all queued up and run as Sharepoint can get around to them.  If you try to copy the file immediately after sending the add row requests, the resulting copy usually occurred before the update requests completed.  We were unable to find a way to specify synchronous operation.  Any tips here? For now, we just have a delay and cross our fingers it is long enough / the server is never busy / down during the time we run the report.

    In the query for results, you can specify columns in the linked entity query, and add query filters, but I could not figure out how to limit columns on the main queried entity.  As a result, our query returns more fields than needed on the main entity (all of them), but only the needed fields on the joined tables.

    Expression language is powerful, but once entered saved, when you return to the flow for edits at a later time, the expressions have been replaced by supposedly user friendly "tags" in the editor. You can hover over them to see the formula, but are no longer able to edit them. Can't copy+paste the original formula, so you just have to take a screenshot of it (or remember it very well) and re-create it if you need to make changes.

    One biggie: Flows are not environment / context aware.  I was unable to specify root environment variables and then switch a flow to run on either sandbox or production. As far as I can tell, all of the queries / update steps had to have their target directories / files hard coded. If anyone has a link on how to set up environment / directory variables and reference them in other steps, I would be grateful for the pointer as this seems to be a pretty big design / documentation hole.

    A few big big plusses: Scheduler is awesome. This and the integration with Excel Online / Sharepoint are why we used Flow to build our weekly report flow.  It is a great start to what will become a massive library of connectors, gives great access to the underlying data (IE JSON HTTP responses) if you are technical, but sometimes the UI gets in the way, as noted above.  The ability to setup a webhook endpoint (I am not aware of any way to set up Dynamics to receive an HTTP messages and process them without custom code) is also a strong point, which I have not used, but we are very much excited to leverage. The ability to replay and see all the results of each step after execution is also HUGE. This makes troubleshooting so much easier. Thank you MSFT! Wish workflows saved / exposed this level of detail.

    Hope MSFT is reading this thread. Overall, Flow is awesome and is making serious headway, but for now I'd agree with the sentiments here that it is still in no way ready to replace Workflows.



    ------------------------------
    Ryan Perry
    Business Systems Analyst
    Auric Solar
    ------------------------------



  • 5.  RE: Say goodbye to Workflow - Time to Go with the Flow

    TOP CONTRIBUTOR
    Posted 4 days ago
    Ryan,
        When you are editing your Flow or LogicApp, after you add a "For Each" action, there is an ellipsis "..." which gives you a Settings option.
    On the Settings is Concurrency Control which defaults to Off, meaning that if you have a query that returns 50 records that you want to iterate over using the For Each, then LogicApps could potentially kick off 50 parallel tasks (depending on resource availability in Azure at the moment you started the LogicApp). If any action inside the For Each is trying to update the same resource (a spreadsheet or a single row in CRM) then the actions are probably going to conflict. Using the Settings/Concurrency Control/Degree of Parallelism, move the slider down to 1 to force it to run the actions sequentially.

    Does that help?

    ------------------------------
    If this answered your question, please click on the arrow button next to Reply Inline and choose 'Make Best Answer.'
    Thanks.
    Nelson Johnson, Solution Architect
    BroadPoint, Inc., Bethesda MD
    Link with me! https://www.linkedin.com/in/nelsonjohnson/
    ------------------------------



  • 6.  RE: Say goodbye to Workflow - Time to Go with the Flow

    GOLD CONTRIBUTOR
    Posted 4 days ago
    @Nelson Johnson, Thank you. This is very helpful. I'd seen some of these settings on the excel add l ine step, but didn't look at those on the loop control. Your explanation was very clear and consice. Do you know, will it enforce completion of last loop's completion before moving onto any steps following the loop? IE all addrow steps must complete before copying the file.

    When I built this I looked at the settings on the excel addrow step. Perhaps because there are so many connectors, documentation is hit and miss. Initially I thought disabling the async pattern was the ticket, but. Can you explain these settings / know where it is documented?

    Also... Any way to specify the filename / path using a variable? ​​

    ------------------------------
    Ryan Perry
    Business Systems Analyst
    Auric Solar
    ------------------------------



  • 7.  RE: Say goodbye to Workflow - Time to Go with the Flow

    SILVER CONTRIBUTOR
    Posted 6 days ago
    Hi,
    We've starting using flow for some things, but as a non-developer its nowhere near ready to be used as a classic workflow replacement.

    Some issues that we've encountered

    • flows aren't properly solution aware - each connection needs to be re-made when you deploy to a new environment. if you have a flow with a lot of steps that is a real pain
    • connections to CDS and other services use your user account not a service account - problematic when users leave
    • flows in solutions aren't easily discoverable - they don't appear in  the D365 processes list and they don't show in the PowerApps flow list. ​
    • its really hard to send an email from dynamics via flow if you are using on-premise exchange . You can't use the native "send email" workflow step and you can't use the O365 email connector so you have to work-around with a HTTP request that calls an action to run a classic workflow to send the email.
    • ODATA is limited in how you can query related data so you have to use XML via HTTP instead.
    • the syntax and expressions in flow are not intuitive and have a steel learning curve - e.g. field case can be really important.
    Flow allows us to do lots of things that the classic workflows can't - scheduling , querying results etc. adhoc data integration/replication.  But thing that are really easy in the classic workflow look really complex in flow.

    As someone who doesn't understand the underlying schema , and webapi  classic workflows "just work". With Flow you need to have a deeper understanding of the tech that enables flow hence the learning curve for users coming to flow from a dynamics "admin" point of view.

    Its not helped by having two CDS connectors that work in different ways - the current environment CDS connector handles regarding records differently and I've not managed to get it working properly.

    The October release looks to address some of the issues I have so I'm looking forward to that.


    ------------------------------
    Matthew Slack
    CRM Functional Specialist
    AQA Education Limited
    Manchester
    ------------------------------



  • 8.  RE: Say goodbye to Workflow - Time to Go with the Flow

    Posted 3 days ago
    Hi, does anybody know if Flow is going to support traditional custom workflow activities in some way? Or should I build a connector to my REST API and do the coding there?

    ------------------------------
    Zarko Radevic
    Dynamics CRM Programmer
    Digitale Medier 1881 AS
    ------------------------------



  • 9.  RE: Say goodbye to Workflow - Time to Go with the Flow

    Posted 3 days ago
    @Zarko Radevic ... I assume in theory flow wouldn't support custom workflow activities due to it having access to more connectors and expressions that people would have had to build custom workflow activities to do.​
    But you are right building a custom connector to your own REST Api is essentially flows version of a CWA


    ------------------------------
    Charles Osei
    Hitachi Solutions America, Ltd.
    Chicago
    ------------------------------



If you've found this thread useful, dive deeper into User Group community content by role