Can a legacy workflow natively react to updates in another table?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi everyone,
I am using the legacy Workflow Editor. My workflow runs on a Requested Item [sc_req_item], but it needs to pause until a related record in a custom table [u_sap_training] changes from pending to either accepted or revoked.
I initially tried using a Wait for Condition activity with a GlideRecord query:
answer = false;
var training = new GlideRecord("u_sap_training");
var trainingSysId = String(
workflow.scratchpad.sap_training_acceptance_sys_id || ""
);
if (training.get(trainingSysId)) {
var status = String(training.getValue("u_status") || "");
answer = status === "accepted" || status === "revoked";
}The script correctly reads the custom table. However, I observed the following behavior:
- The workflow entered the Wait for Condition activity while the training record was pending.
- I changed the record in [u_sap_training] to accepted.
- The workflow remained in the Waiting state.
After I updated a field on the RITM, the Wait for Condition was re-evaluated and the workflow continued, as expected. However, this does not meet my requirement, since I need the workflow to react to the update in the related table without requiring an update to the RITM.
I understand that there are external ways to wake the workflow (aside from timer-based polling, which I do not consider a suitable solution because I am looking for an event-driven approach), like using a script in a second workflow that runs on the table we want to monitor, Business Rules or Script Includes using broadcastEventToCurrentsContexts(), or even forcing an update on the RITM with:
ritm.setForceUpdate(true); ritm.update();
All these solutions depend on something being executed outside the original RITM workflow.
-> So my first question is:
Am I using the GlideRecord query incorrectly in the Wait for Condition script, or is a GlideRecord query simply not capable of acting as a listener for changes in another table and causing the waiting workflow to resume when those changes occur?
-> My second question is:
Does the legacy Workflow Editor provide any native mechanism that can be configured entirely within the original RITM workflow to monitor a specific record in another table and automatically resume the RITM workflow when that record is updated?
For example, can a Wait for Condition activity be configured so that an update to a related record in another table automatically causes its condition script to be re-evaluated?
Similarly, can a Wait for WF Event activity be configured within its own workflow to automatically react to updates made to a record in another table?
Or must some mechanism outside the waiting workflow context always detect the external record update and then explicitly cause the condition to be re-evaluated or send an event to that workflow context?
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
workflow wait for condition only listens to changes to fields on the record against which the workflow is running.
It doesn't react to updates on other record
In past I shared solution on how to broadcast an update and workflow wait for condition evaluates and then can proceed
Example: have after update BR on u_sap_training, condition as Status Changes to Accepted OR Resolved
(function executeRule(current, previous /*null when async*/) {
var wf = new Workflow();
var ri = new GlideRecord("table on which workflow is running");
if (ri.get(current.fieldReferringThatTable)) {
wf.runFlows(ri, 'update');
}
})(current, previous);
💡 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
