- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi All,
As our company continues to enhance and standardize our ServiceNow configurations, I would like to understand team preferences and experiences regarding custom scripting versus Flow Designer for automation and logic.
Please share your perspective on the following:
Which approach do you generally prefer (scripting or Flow Designer)?
In what scenarios do you find one more effective than the other?
Any limitations or challenges you have encountered with either option
Your input will help guide future design decisions, establish standards, and ensure we are balancing maintainability, scalability, and delivery speed appropriately.
Thank you in advance for your feedback!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @Matthew_13
1) I generally prefer to go to Flow Designer first , as it provides drag-and-drop data pills, Flow branches, Actions and testing execution which makes development faster and easier to follow.
2) I prefer scripting when the use case is more complex. With AI tools and a good understanding of scripting, now even scripting has become little easier to implement and maintain advanced logic. For simpler scenarios which has less number steps I usually choose flow designer for use cases like approvals, simple updates of record. Also for integration if spokes are readily available flow designer it makes for simple and cleaner approach
3) I’ve noticed with Flow Designer is that it sometimes does not auto-save and requires/ forces manual saving, which can be frustrating during development and personally I find flow designer scripting little bit challenging.
For scripting one should ideally include proper error handling such as try-catch blocks for easier debugging.
Thanks and Regards,
Mohammed Zakir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @Matthew_13,
To add to what @Mohammed8 said:
My general approach is to start with no code/low code options first, which would be flow designer. I only consider custom scripting when there is a clear need.
Flow designer is seriously great for the majority of things you will need like orchestration, approvals, integrations, and logic that is easy to read and maintain. I've only run into one approval scenario that couldn't be done in flow designer. For that specific case, I used a workflow and called it in my flow.
One important consideration is support ownership. ServiceNow supports their OOTB options, but once you get into heavy customizations, you will be responsible for maintenance, debugging, and optimizations. It is very easy to rack up technical debt when you choose customization as the first option, and often creates more work when it's time to upgrade.
And just a final thought from my experience working with various clients. There will be times when you want to consider ways to cut costs. Really think these decisions through as it can cost you more in the long run. It's always worth pausing and asking yourself... is this scalable? are we able to maintain long term? I've been apart of many projects where the sole purpose is to reverse previous work.
I hope this helps!
Sr. ServiceNow Developer | Infosys
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @Matthew_13
1) I generally prefer to go to Flow Designer first , as it provides drag-and-drop data pills, Flow branches, Actions and testing execution which makes development faster and easier to follow.
2) I prefer scripting when the use case is more complex. With AI tools and a good understanding of scripting, now even scripting has become little easier to implement and maintain advanced logic. For simpler scenarios which has less number steps I usually choose flow designer for use cases like approvals, simple updates of record. Also for integration if spokes are readily available flow designer it makes for simple and cleaner approach
3) I’ve noticed with Flow Designer is that it sometimes does not auto-save and requires/ forces manual saving, which can be frustrating during development and personally I find flow designer scripting little bit challenging.
For scripting one should ideally include proper error handling such as try-catch blocks for easier debugging.
Thanks and Regards,
Mohammed Zakir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @Matthew_13,
To add to what @Mohammed8 said:
My general approach is to start with no code/low code options first, which would be flow designer. I only consider custom scripting when there is a clear need.
Flow designer is seriously great for the majority of things you will need like orchestration, approvals, integrations, and logic that is easy to read and maintain. I've only run into one approval scenario that couldn't be done in flow designer. For that specific case, I used a workflow and called it in my flow.
One important consideration is support ownership. ServiceNow supports their OOTB options, but once you get into heavy customizations, you will be responsible for maintenance, debugging, and optimizations. It is very easy to rack up technical debt when you choose customization as the first option, and often creates more work when it's time to upgrade.
And just a final thought from my experience working with various clients. There will be times when you want to consider ways to cut costs. Really think these decisions through as it can cost you more in the long run. It's always worth pausing and asking yourself... is this scalable? are we able to maintain long term? I've been apart of many projects where the sole purpose is to reverse previous work.
I hope this helps!
Sr. ServiceNow Developer | Infosys
