Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Architecture Overview

Log in to subscribe to topics and get notified when content changes.

Architecture Overview

Understand how Flow Designer works within the Now Platform to activate, trigger, and process flows and actions.

A flow consists of a trigger and one or more actions. The trigger specifies when to start the flow, which can be record-based, schedule-based, or application-based. Record-based triggers run a flow after a record has been created, updated, or deleted. The flow can use the triggering record as input for actions. Schedule-based triggers run a flow at the specified date and time. The flow can use the execution time as input for actions. Application triggers are added when the associated application is activated. For example, the MetricBase trigger is present when the MetricBase application is active.

Flow processing

Flow processing occurs in this sequence.
  1. When the flow trigger conditions occur, the system creates an entry in the event queue to start the flow.
  2. The scheduler processes the event and starts the flow in the background.
  3. The system builds a process plan from the flow.
  4. The system runs the process plan using the record that triggered the flow.
  5. The system stores the execution details in a context record.

Flow processing diagram

1. Process flow triggers
Each time trigger conditions are met, Flow Designer creates an event entry. The system processes triggers after database operations. To learn more, see Execution order of scripts and engines. Typically, business rules and workflows that run synchronously run before a triggered flow.
2. Process events in the queue
Each flow event contains a reference to the flow to start and a reference to either the triggering record or the execution time. The system processes these events using Standard event processing where a scheduler periodically works through the current items in the event queue in the order in which they were added. Depending on what other events are in the queue, the system may not immediately start a flow. Flow designers should expect some lag time between when the trigger conditions occur and when the flow actually starts.
3. Build the process plan

When Flow Designer pulls an event from the queue, it builds a process plan to actually run the flow. A process plan contains all the information necessary to execute a flow such as the sequence of published actions or subflows, the input values for each subflow or action, the action steps to run for each action, and the data provided by the trigger or subflow output.

Flow Designer uses a just-in-time compilation scheme to ensure that process plans contain the latest changes to flows, subflows, and actions. If no changes are detected, Flow Designer uses a cached copy of the process plan. Otherwise, it builds a new process plan.

By automatically checking for updated flows, subflows, and actions with process plans, Flow Designer enables you to apply changes from update sets and upgrades without having to edit current flows. If you move published actions to a target instance, every flow that uses the published action will automatically update the next time it is executed.

Warning: If changing subflows or actions used in activated flows, do not change the inputs and outputs used in the subflow or action. Changing inputs and outputs may cause errors when the activated flow is next triggered because it has not been configured to use the new inputs and outputs. Any currently running flows are unaffected by changes to inputs or outputs as the flow uses the compiled subflows and actions from the process plan.
4. Run the process plan

Flow Designer runs the process plan as the System user within the flow application scope.

When running a flow with a record-based trigger, Flow Designer stores the triggering record in memory as an instance that is represented in the interface as a data pill.

The instance contains the record values from when the flow started, which may be different than the current record stored in the database. For example, suppose that creating an incident record triggers a flow. Any changes a user makes to the incident record after the flow has started do not update the triggering record unless an action specifically looks up the current record value.

5. Store flow execution details

Flow Designer stores flow execution details in a flow context record, which contains this information.

  • Flow outcome state
  • Flow runtime duration
  • Flow log messages
  • Flow configuration and runtime values

Each time a flow runs, Flow Designer adds an entry to the Flow Executions list. Each entry has its own context record and matching execution details page.

A flow can have one of these outcome states.

State Description
Complete The flow completed successfully.
In Progress The flow is running. By default, a transaction quota rule prevents flows from running longer than an hour.
Waiting The flow is waiting for another event to occur. For example, a user must update a task or approval, or a record must reach a specific state. When in the waiting state, the flow is quiesced and serialized into a context record.
Canceled The flow was canceled by a user.
Error The flow encountered an error and has stopped running. For example, an action is missing an input value, or a quota transaction rule has stopped the flow.

Flow, subflow, and action life cycle

Flow Designer uses the flow or action status to describe the current state of configuration changes.

Flow and subflow status and activation state

The Status field indicates whether there is a process plan associated with the flow or subflow.

Flow status Description
Modified Indicates that there are unsaved changes to a flow or subflow. Modified flows or subflows have not been saved.
Draft Indicates that there are saved changes to a flow or subflow, which have not been stored in a process plan. Draft flows have been saved but not activated. Draft subflows have been saved but not published.
Published Indicates that there is a stored process plan for the flow or subflow. Published flows have either been activated or deactivated.

The Active field indicates whether the system runs a flow or subflow.

Active Description
True Indicates that the flow or subflow is active and runs when triggered or called. The flow has been activated or the subflow has been published. Active flows run when the trigger conditions are met or when called. Active subflows run when called.
False Indicates that the flow is inactive and does not run when triggered or called. An inactive flow has either never been activated or has been deactivated. An inactive subflow has never been published.
When working with flows, you can:
  • Save a flow: Creates a draft of the flow.
  • Activate a flow: Enables the flow trigger and transform the flow into a process plan.
  • Deactivate a flow: Disables the flow trigger and prevents new flow executions. Currently running flows continue to run.

When working with subflows, you can:

  • Save a subflow: Creates a draft of the subflow. If the subflow is modified after being published, the subflow moves into a draft state. Any active flows that use the subflow only run the published action.
  • Publish a subflow: Enables you to activate a flow containing the subflow. Publishing adds the subflow to the list of available subflows in a flow.

Flow life cycle diagram
Action status

The Action Designer interface does not display the configuration status of actions. To view action status, navigate to the Action Types table [sys_hub_action_type_definition] and display the Draft state field.

Action Draft status Description
Draft Indicates that there are changes to an action that have not been published. Draft actions are only available to flows when the Show draft actions option is enabled. You cannot activate a flow containing draft actions.
Published Indicates that the action has been published. Published actions are available to all flows and allow flows to be activated.

When working with actions, you can:

  • Save an action: Creates a draft of the action that is only available to flows when Show draft actions is enabled. If the action is modified after being published, the action moves into a draft state. Any active flows that use the action only run the published action.
  • Publish an action: Enables you to activate a flow containing the action. Publishing adds the action to the list of available actions in a flow. Only actions in a published state run during flow execution.

Action life cycle diagram

Application development

When designing an action or a flow, use these design considerations as a guide.

Use standard Now Platform application development capabilities to create, manage, protect, and deploy Flow Designer content. Flow and action designers typically perform these application development tasks.
  • Create a custom application to store flows and actions.
  • Set application permissions to share or restrict access to application data.
  • Grant application developers access to Flow Designer.
  • Publish custom applications to the application repository to deploy flows and actions on other instances.


Control access to Flow Designer processes and records.

  • Administrators can grant users access to Flow Designer by creating an application and assigning users as developers with the Flow Designer delegated development permission. Delegated development allows administrators to control whether flow designers can access features normally restricted to admin users such as assigning user roles, creating access controls, or creating scripts. See Developer permissions.
  • Administrators can also grant access to Flow Designer by directly assigning users the flow_designer user role, which includes the role to view flow execution details.
    Warning: Directly granting a user the flow_designer role is equivalent to giving the user the admin role, because Flow Designer can run flows as the System user, which has access to all tables and all database operations.
  • Flow and action designers can use standard Application access settings to manage how their content interacts with other applications.

Action limit

By default, flows can have no more than 50 actions. To change the default behavior, increase the value of the sn_flow_designer.max_actions system property. However, consider the performance impact that a large flow may have on your instance.

Trigger options for record updates

Flow designers can specify how often a flow can update a particular record with the Run Trigger option. Use the Once option when you want a flow to run only once. The first time a record is updated, the flow runs, but any further record updates do not trigger the flow. Use the Always option when you want the flow to run every time a record is updated and there is not already an active flow running for it. For example, you might set a flow that assigns an incident record to run only once, and set a flow that notifies the incident watch list to always run. The Run Trigger field is only available for these trigger types.
  • Created or Updated
  • Updated

Direct recursion prevention and indirect recursion limit

To prevent instance outages and consumption of system resources, Flow Designer ignores any request to start a flow that is the result of direct recursion. Direct recursion occurs under these conditions.
  • An action calls the same flow that it is part of. For example, a script step makes an API call to a flow.
  • An action or subflow produces a result matching the flow trigger. For example, a flow that runs when an incident record is updated contains an update record action that updates an incident record.
Flow Designer also limits the number of times a flow can be started from indirect recursion. Indirect recursion occurs under these conditions.
  • The same flow is called multiple times in a chain of subflow calls. For example, if subflow A calls subflow B, and subflow B calls subflow A, then calling either subflow produces indirect recursion.
  • The same flow is triggered multiple times in a chain of subflows. For example, suppose that there are two flows triggered by record creation. Suppose that creating record A triggers flow A and also creates record B. Furthermore, creating record B triggers flow B and creates record A. Creating either record type produces indirect recursion.

By default, the system stops triggering flow runs after the run count reaches the indirect recursion limit of three runs. Administrators can change the limit by setting the system property com.glide.hub.flow_engine.indirect_recursion_limit to an integer value equal to or greater than one. The system ignores any property value less than one and instead uses a limit of one. Consider the performance impact that increasing the indirect recursion limit may have on your instance.

Note: By default, a transaction quota rule prevents flows from running longer than an hour.

Flow and action testing

Testing a flow bypasses the trigger conditions and immediately runs it. Testing a flow with a record-based trigger requires selecting a specific record to act as the trigger. Flow designers should generate appropriate sample records prior to testing.

During the design phase, you can test an inactive flow and unpublished actions by setting Show draft actions on the flow. If testing with draft actions, use these guidelines.

  • Design flows and actions on a non-production instance. Only deploy active, working flows to your production instance.
  • Leave Show draft actions set to true until your draft is in a final state. Once final, publish each action, set Show draft actions to false, and activate the flow.
    Warning: Disabling Show draft actions before publishing your actions removes all draft actions from your flow.
  • Any change you make to an active flow or published action causes it to return to a draft state. If the flow is triggered, the system only runs the activated flow and published actions, and the flow execution details only display what was run. When there is a draft of an active flow, the trigger and actions listed in the flow execution details may be different than those listed in the draft flow.