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 either be record-based or schedule-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. Flow processing Flow processing occurs in this sequence. When the flow trigger conditions occur, the system creates an entry in the event queue to start the flow. The scheduler processes the event and starts the flow in the background. The system builds a process plan from the flow. The system runs the process plan using the record that triggered the flow. The system stores the execution details in a context record. 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, the input values for each action, the action steps to run for each action, and the data provided by the trigger. Flow Designer uses a just-in-time compilation scheme to ensure that process plans contain the latest changes to flows 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 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 actions used in activated flows, do not change the inputs and outputs used in the 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 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 and action life cycle Flow Designer uses the flow or action status to describe the current state of configuration changes. Flow status and activation state The Status field indicates whether there is a process plan associated with the flow. Flow status Description Modified Indicates that there are unsaved changes to a flow. Modified flows have not been saved. Draft Indicates that there are saved changes to a flow, which have not been stored in a process plan. Draft flows have been saved but not activated. Published Indicates that there is a stored process plan for the flow. Published flows have either been activated or deactivated. The Active field indicates whether the system runs a flow. Active Description True Indicates that the flow is active and runs when triggered or called. The flow has been activated. Active flows run when the trigger conditions are met. False Indicates that the flow is inactive and will not run when triggered or called. An inactive flow has either never been activated or has been deactivated. 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. 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. 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. Security 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 runs 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 20 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 Data pill population Each time you add an action to a flow, Flow Designer adds a data pill to store its results. The data pill name indicates its sequence in the flow and its data type. Flow designers use action result data pills to provide input for other actions. Flow designers can use the sequence value in the data pill name to ensure they select the correct data pill as an input value. When a flow runs an action, it generates the data pill runtime value, which remains the same for the duration of the flow. For example, a data pill for [Trigger->Incident record] always contains the incident record values from when the flow started. Flow Designer populates data pill values as soon as the data becomes available regardless of where the data pill is located in the flow sequence. For example, suppose that you have a flow triggered by the creation of an incident record with the following actions. Update [Incident] Record that adds a text string to [Trigger->Incident Record->Short description]. Log the value of [Trigger->Incident Record->Short description]. Log the value of [1->Incident Record->Short description]. Action-1 and Action-2 both use the data pill [Trigger->Incident Record->Short description]. Since the trigger record is available as soon as the flow starts, these values are set before running these actions. 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 sub-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.