Can a legacy workflow natively react to updates in another table?

[jyunes17]

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:

1. The workflow entered the Wait for Condition activity while the training record was pending.
2. I changed the record in [u_sap_training] to accepted.
3. 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.