Flow designer approvers called from decision table not triggering

[Shraddha17]

I have configured decision table having requestor's organization stored in combination with organization's approver. When I call this decision and pass input as Requested For (from Get catalog variable) the approval is not getting triggered. However, when a "Test" the flow from flow designer interface, the approval gets triggered. What am I missing ?

[VJ_Srivastava]

Hello Shraddha,

From a platform architecture perspective, the behavior you are experiencing highlights a fundamental principle in enterprise workflow automation: the divergence between administrative testing environments and actual transactional runtimes.

When relying on Decision Tables to govern dynamic approvals, relying solely on the "Test" feature in Flow Designer can create blind spots in your deployment pipeline. The Test function is designed to validate logical pathways, but it inherently masks security architecture (ACLs) and transactional state anomalies by executing under high-level administrative privileges.

To build robust, enterprise-grade automations, we must engineer defensively against these runtime variations. Here is how I advise structuring this to prevent technical debt:

• Contextual Abstraction: Approval matrices tied to organizational hierarchy should always be abstracted from the end-user's security context. If your flow is set to "Run as User", you are tightly coupling internal HR/Organizational data visibility to standard requester ACLs. Reconfigure the Flow to execute as the "System User." This standardizes the execution payload and ensures deterministic behavior regardless of who submits the request.

• Idempotent Execution: When querying reference variables (like the "Requested For" user record) immediately after a catalog submission, race conditions can occur. Designing the architecture to gracefully handle null returns—such as routing to a default fallback approval group if the decision table returns empty—prevents the workflow from silently bypassing governance.

• Release Management: Ensure that every dependency (Subflows, Actions, and Decision Tables) is packaged and published simultaneously. A frequent architectural oversight is publishing the Flow while leaving the referenced Decision Table in a Draft state, which causes live execution failures.

Standardizing your testing protocols to include mandatory impersonation of standard users during User Acceptance Testing (UAT) will catch these context-based failures before they reach production.

[NehaG8791370651]

Hi Shraddha,

This is a classic Flow Designer troubleshooting scenario! When a flow executes perfectly in the "Test" interface but fails during live runtime, it almost universally points to a discrepancy in the execution context rather than a logical flaw in your Decision Table.

In the ServiceNow architecture, the "Test" button is a highly privileged action. It executes the flow using your current administrative session and bypasses several background processes. Here is a structured breakdown of the three most likely culprits and how to resolve them:

• The "Run As" Execution Context (Most Likely): By default, Flow Designer triggers run as the "User who initiates the session." When a standard end-user submits the catalog item, the flow runs with their security profile. If they lack Read ACLs to the organizational table, the Decision Table, or specific user records, the "Get Catalog Variables" or Decision Table lookup will return null, silently skipping the approval.

  • Fix: Open your Flow properties and change the "Run As" setting from User who initiates session to System User. This ensures the flow can query the organizational hierarchy regardless of the requester's ACLs.

• Draft vs. Published States: The "Test" feature intentionally runs the most recent Draft version of your flow and calls the latest Draft of your Decision Table.

  • Fix: Double-check that both your Flow and the Decision Table itself are fully Published. If the Decision Table is in a draft state, live flows will ignore it.

• Database Commit Timing: In "Test" mode, you are passing an existing, fully committed record. In runtime, if the flow triggers immediately upon submission, there can occasionally be a microsecond race condition where the requested_for variable hasn't fully committed to the sc_item_option_mtom table before the "Get Catalog Variables" action fires.

  • Fix: Add a brief "Wait for a duration" (e.g., 10 seconds) at the very beginning of your flow to guarantee all variable relationships are securely committed to the database before the decision table attempts to read them.

Check your flow execution context first, as that resolves 90% of these runtime discrepancies!

[masonreed11]

Check that the runtime input matches what the decision table expects. The Requested For variable may not be resolving to the user's organization during flow execution, even though the test uses different data. Logging the input value usually reveals the issue.