- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I have created a flow that implements "Wait For Condition."
This flow is executed about 50 times a day, and all flows are in a wait state.
The next day, the wait release conditions are met and the flows are processed.
I feel that having around 50 flows in a wait state continuing for a day may be affecting ServiceNow's performance.
Does "Wait For Condition" constantly monitor records?
It would be fine if the monitoring frequency was low, but it would be scary if it was monitoring once every few seconds to milliseconds.
Will this work when updated like a business rule with a record update trigger?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @bonsai ,
Monitoring Mechanism
The activity registers a "record watcher" (visible in sys_rw_action table) that triggers evaluation only when the target record is updated via database commits, such as through business rules, UI actions, or scripts. It checks the specified condition at that moment, resuming the flow if met. This avoids continuous monitoring, making it efficient even for 50 daily waits spanning a day.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
yes this will cause performance impact in PROD since the table data could be huge.
You can use after update BR and make your BR trigger when that wait condition is met i.e. some field get updated etc
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @bonsai,
From my experience, the “Wait for Condition” action in Flow Designer doesn’t constantly monitor the record in real time. When the flow reaches that step, the execution is basically paused and stored by the platform, and it waits there until the defined condition becomes true.
ServiceNow doesn’t keep checking the condition every few seconds or milliseconds. Instead, it generally re-evaluates the condition when the related record is updated, similar to how a business rule reacts to a record change. So it’s more of an event-driven process rather than continuous monitoring.
Because of that, having around 50 flows in a wait state for a day shouldn’t create any noticeable performance impact. The platform is designed to handle paused flow contexts efficiently, and they don’t actively consume resources while waiting.
In most cases, performance concerns would only start appearing if there were thousands of flows stuck in wait states or if the condition was tied to records that are updated extremely frequently. For your scenario, the setup you described should work perfectly fine.
You can refer to these latest Zurich version documents of "wait for condition." I hope this answers your question.
https://www.servicenow.com/docs/r/build-workflows/workflow-studio/wait-for-condition-activity.html
If you find my answer useful, please mark it as Helpful and Correct.
Regards,
Soham Tipnis
ServiceNow Developer || Technical Consultant
LinkedIn: www.linkedin.com/in/sohamtipnis10
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @bonsai ,
Monitoring Mechanism
The activity registers a "record watcher" (visible in sys_rw_action table) that triggers evaluation only when the target record is updated via database commits, such as through business rules, UI actions, or scripts. It checks the specified condition at that moment, resuming the flow if met. This avoids continuous monitoring, making it efficient even for 50 daily waits spanning a day.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
yes this will cause performance impact in PROD since the table data could be huge.
You can use after update BR and make your BR trigger when that wait condition is met i.e. some field get updated etc
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hope you are doing good.
Did my reply answer your question?
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @bonsai,
From my experience, the “Wait for Condition” action in Flow Designer doesn’t constantly monitor the record in real time. When the flow reaches that step, the execution is basically paused and stored by the platform, and it waits there until the defined condition becomes true.
ServiceNow doesn’t keep checking the condition every few seconds or milliseconds. Instead, it generally re-evaluates the condition when the related record is updated, similar to how a business rule reacts to a record change. So it’s more of an event-driven process rather than continuous monitoring.
Because of that, having around 50 flows in a wait state for a day shouldn’t create any noticeable performance impact. The platform is designed to handle paused flow contexts efficiently, and they don’t actively consume resources while waiting.
In most cases, performance concerns would only start appearing if there were thousands of flows stuck in wait states or if the condition was tied to records that are updated extremely frequently. For your scenario, the setup you described should work perfectly fine.
You can refer to these latest Zurich version documents of "wait for condition." I hope this answers your question.
https://www.servicenow.com/docs/r/build-workflows/workflow-studio/wait-for-condition-activity.html
If you find my answer useful, please mark it as Helpful and Correct.
Regards,
Soham Tipnis
ServiceNow Developer || Technical Consultant
LinkedIn: www.linkedin.com/in/sohamtipnis10
