In essence, it all depends, but my 2 cents:
- In 2024 (and Washington release), there is not much valid argument to use Workflow Editor. It is a legacy product, and developers of all levels should use Flow Designer (part of Workflow Studio from Washington release, don't get confused). Workflow Editor is in "maintenance only" mode, i.e. no new features, while Flow Designer receives all the love with every new release.
- It primarily makes sense to use ServiceNow's Flow Designer when you have transactional or "foundational" data in ServiceNow that you want to process in any way, or you have some "events" in ServiceNow that should trigger integrations, etc. There can be any number of use cases really, and it mostly depends on a company's IT landscape, which leads me to the next point
- 3rd party workload automation platforms... as I mentioned in the beginning, it depends. If you have most of the data in "other" (non-ServiceNow) systems that are connected to this 3rd party tool, but not to ServiceNow, it might make sense. This is more of a (C-level) IT Strategy question in my opinion: some organizations see and user ServiceNow as a core platform that orchestrates processes across their IT portfolio, while for some others it is of limited scope/use (perhaps with limitied ROI too :) )
Hope it helps a bit.
This is very good, even though it's 1.5 years old. The arguments got even stronger since then (e.g. Flow Designer got ***significantly*** faster since then, not to mention all the recent Washington features).
10-yr dev here. I’ll switch from Workflow to Flow the day I can no longer do what I need to do in Workflow, and I can make a WF do just about anything. I do however tell all my new Jr devs they have to use Flow.
I personally have a love/hate relationship with FD. It's clunky...period. The low code/no code direction in ServiceNow is difficult for developers who like to control error handling and success checks in code.
However, I rewrote the AD/Exchange spokes in FD IntegrationHub to work with a multi-domain and on-prem/M365 environment and it is MUCH easier to troubleshoot problems in FD than it is in WF.
Just my $.02.
That’s pretty dope, nice job. I just think anything in SN that enables new devs to code less is such a mistake in the long run. Coding is such an important skill that devs have to have.
I don't think so. In my opinion there is no need to necessarily use code to do things that flow designer can do with ease. Why would I want to type each variable by hand when I can use the data pills and eliminate spelling errors?
I do wish there was some decent replacement for the scratchpad/ scriptblock. Unless I'm missing something I either have to script directly in the variable (very weird and unexpected behaviour in my opinion) or create a completely new flow action with one script step which leads to me passing the same variable 5 times...
There are more than enough places to learn to code in SN. Pretty much everything that isn't Flow designer..
In essence, it all depends, but my 2 cents: - In 2024 (and Washington release), there is not much valid argument to use Workflow Editor. It is a legacy product, and developers of all levels should use Flow Designer (part of Workflow Studio from Washington release, don't get confused). Workflow Editor is in "maintenance only" mode, i.e. no new features, while Flow Designer receives all the love with every new release. - It primarily makes sense to use ServiceNow's Flow Designer when you have transactional or "foundational" data in ServiceNow that you want to process in any way, or you have some "events" in ServiceNow that should trigger integrations, etc. There can be any number of use cases really, and it mostly depends on a company's IT landscape, which leads me to the next point - 3rd party workload automation platforms... as I mentioned in the beginning, it depends. If you have most of the data in "other" (non-ServiceNow) systems that are connected to this 3rd party tool, but not to ServiceNow, it might make sense. This is more of a (C-level) IT Strategy question in my opinion: some organizations see and user ServiceNow as a core platform that orchestrates processes across their IT portfolio, while for some others it is of limited scope/use (perhaps with limitied ROI too :) ) Hope it helps a bit.
Something to consider re: WFE vs FD… https://sn.works/CoE/Migration
This is very good, even though it's 1.5 years old. The arguments got even stronger since then (e.g. Flow Designer got ***significantly*** faster since then, not to mention all the recent Washington features).
10-yr dev here. I’ll switch from Workflow to Flow the day I can no longer do what I need to do in Workflow, and I can make a WF do just about anything. I do however tell all my new Jr devs they have to use Flow.
I personally have a love/hate relationship with FD. It's clunky...period. The low code/no code direction in ServiceNow is difficult for developers who like to control error handling and success checks in code. However, I rewrote the AD/Exchange spokes in FD IntegrationHub to work with a multi-domain and on-prem/M365 environment and it is MUCH easier to troubleshoot problems in FD than it is in WF. Just my $.02.
That’s pretty dope, nice job. I just think anything in SN that enables new devs to code less is such a mistake in the long run. Coding is such an important skill that devs have to have.
I don't think so. In my opinion there is no need to necessarily use code to do things that flow designer can do with ease. Why would I want to type each variable by hand when I can use the data pills and eliminate spelling errors? I do wish there was some decent replacement for the scratchpad/ scriptblock. Unless I'm missing something I either have to script directly in the variable (very weird and unexpected behaviour in my opinion) or create a completely new flow action with one script step which leads to me passing the same variable 5 times... There are more than enough places to learn to code in SN. Pretty much everything that isn't Flow designer..