Flow Designer or Business Rule and ScheduleOnce

[Ryan146]

Dear community,

We are having a requirement which are debated within the team about the preferable solution. So I decided to get the support from the community.

The requirement:

- To automatically send out the email reminder when the Incident has been in the state = "Awaiting for user information" for 3 days.

- Within 3 days, if the Incident state changes then we do not send the reminder email.

Solution 1:

- Create Business Rule #1 that trigger when the incident state changes to "Awaiting for user information".

This business rule will run a script that create a scheduleOnce job with a name identifier (Ex:Incident number) that will be executed after 3days to send out the reminder email.

- Create Business Rule #2 that trigger when the incident state changes from "Awaiting for user information" to some different states.

This business rule will run the script that look up for the scheduled job with the name identifier created from the above business rule and deactivate it.

Solution 2:

- Create a Flow that trigger when the state changes to "Awaiting for user information". (See attached image for example)

There will be a parallel step which run 2 following branches at the same time:

• Branch 1: Create a flow logic step "Wait for a duration of time" activity that wait for 3 days, after that will send out reminder email.
• Branch 2: Create a "Wait for Condition" step that trigger when state changes to some values not "Awaiting for User Information". When the condition met "End Flow" (This is a flow logic step from OOB)

Some of the points that were brought up within the team:

• Using flow will be a simplifier approach which help reduce system complexity.
• Many active flow contexts will cause performance impact to the system.
• With the flow contexts, it will easier to maintain and debug issue.

Kindly let us know your thoughts on which solution that will best support the maintainability and system performance efficiency.

Thank you so much for your supports. 

[Mark Manders]

Solution one will be terrible to troubleshoot. Your flow executions will be in 'wait' and won't impact the performance that much. Go with the flow!

FYI: you could also utilize metrics within your flow. Since state changes are already (OOB) used within metrics, you could just wait for 3 days, and then check if there have been any state changes since the start of the flow. If so, end it, if not, send the email. A simple lookup to the metric instance table could do the trick.

[Community Alums]

hi @Ryan146 ,

I’ve implemented a similar requirement before, where we had to send a notification every 8 hours while the incident stayed in the “Awaiting for user information” state, and after the 5th notification the incident was auto-closed.

From my experience:

• Using Flow: technically possible, but it leads to thousands of active flow contexts if many incidents go into that state at the same time. Each context consumes system resources and can eventually block threads, which has a real performance impact—especially in busy environments.

• Business Rules: you could do it, but you’d end up writing relatively complex logic to schedule and cancel jobs based on state changes. It works, but maintenance can become tricky over time.

Best approach:
Use a Scheduled Job (Scheduled Script Execution). You can:

• Schedule a job (e.g., run every hour) that looks for incidents which have been in “Awaiting for user information” for more than 3 days and haven’t been updated.

• Send reminders as needed.

• If required, extend the logic to keep sending reminders or auto-close after certain criteria.

This keeps things lightweight:

• No need to track individual timers per record.

• No thousands of flow contexts.

• Easier to manage and debug: just one scheduled script that handles all records in scope.

Hope this helps! Let me know if you'd like an example script or design for the scheduled job.

[Ryan146]

Hi, thank you for your sharing of the experience.

Could you please share the sources about Flow contexts consume system resources and block threads? Or may some scenarios that I can set up for testing on my PDI to see the performance impact?

I do see back and forth discussion about this topic but never get a reliable sources or any testing scenarios from the community and ServiceNow. So it still a myth to me if not for all the others.

Sorry for many asks and thank you so much for your support!