When to use Flow Designer vs Workflow Editor?

[peterraeves]

I am learning up on the new Flow Designer / IntegrationHub.

What confuses me is, what this offers more than the workflow editor. It just seems like WEv2, with the same functionality, but with a different UI around it. Though I have to admit that it makes flows easier to create, there is one very big flaw with FD, what makes me think I will not use it often, is the fact that you cannot script the condition... 

So in what cases should I best use the WE? And in what cases should I best use the FD?

[peterraeves]

Workflow Editor has the same extension, called Orchestration 😉

Okay, so basically I should see FD as the 'ServiceNow Express' variant of WE.

The issue is, that if you would try to create a flow with FD and notice that you do need some scripting, you really need to completely start over in WE. So I am not sure, whether I would want to take the risk wasting time there. I really hope there will come an 'advanced' version in one of the upcoming releases, as I do see a lot of potential in the FD.

[Arun81]

Flow Designer is a cool stuff and it is going to change the way developers do their work going forward. 

So far below are the two rules i am following for Flow Designer:

1. If you starting newly you should start with the Flow Designer.
2. If your change requests require larger implementation in the already existing use-case you can start with Flow Designer

Think of Flow Logics as the lego structures and Action Logics are the lego blocks - Once you started using it you gonna love it and will start building cool use cases down the line.

Enabling the Administrators and Process owners to build their automation use cases themself (without the knowledge of scripting) is just one use case.

The real goal behind the invention of FD is: Getting rid of silos, Discoverability, Re-Usability,Run on Mid Server

Replacing silos not only for customer it is for developers as well - One place for Automation

• With flow designer all the automation come down to single place - Business Rules , Schedule Jobs, Workflows,Orchestrations, Inbound/Outbound Rest Integrations will be a thing of past

Discoverability

• How many of you (Architects) have maintained the list of script includes and their use-case and reference it during the code review and caught your developers that they re-invented something which already in-place. This is a thing of past now. Since All the (scripted) customization are available at single place. Developers can spend their precious time time in building the new stuff.

Re-use

• Very common problem in organization that over a period of time having we end-up with so many script includes at the end of the day we will came to know that many of them does the same stuff, each developer tend to develop their own script includes without knowing there is something already one available. This is a thing of past as we can create a Reusable Action Logics which serves as a building blocks for Flow Logics.

Mid Server

• You might come across that you would needed to run your transaction in the Mid Server. With FD you can run it in Instance as well as MidServer

Madrid adds more cool stuffs to the Flow Designer and one of them is the new application Decision Tables.

[patricklatella]

Has anyone experienced the issue where an "Ask For Approval" step in a Flow is resetting later in the Flow?  I've got a 1st and 2nd approvals with different approvers.  The first approval runs fine.  But then when the 2nd "Ask For Approval" runs, it is resetting all the approvals in the 1st "Ask For Approval" back to "Requested".  Each "Ask For Approval" has a different set of users.  Anyone know what's happening here?  Thanks!

[Sudhanshu Talw1]

Give at least 5-10 sec wait for condition. It is a workaround i read on a knowledge article.

Thanks

Sudhanshu

[patricklatella]

Thanks Sudhanshu for the tip...after which Step should I put that?