--- sourceDocument: Yokohama Build workflows sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/build-workflows Release : - yokohama ft:locale : - en-US ft:publication_title : - Yokohama Build workflows ft:clusterId : - crworkflow bundleId : - crworkflow workflow : - Creator --- # Flow roles # Flow roles {#ariaid-title1} Release version: Yokohama Updated January 30, 2025 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Flow roles Flow roles in ServiceNow Yokohama release allow you to create flows and subflows that execute with specific roles, enabling user-initiated flows to run under designated roles rather than the initiating user's roles. This feature enhances control over flow permissions and execution context. Show full answer Show less ## Role Selection and Assignment * Flows can run either as the system user or as the user who initiates the session. * Roles can only be assigned to flows running as the initiating user; system user flows run with the system role and do not support individual role assignment. * Multiple roles can be assigned to a flow, but selecting new roles replaces the original roles. * If no roles are assigned, the flow runs with the roles of the initiating user. * Assignable roles depend on your own roles and the flow's application scope, excluding high-security roles such as **admin** , **securityadmin**, and application-specific admin roles. ## Flow Modification and Copying * Users can modify flows only if they have all roles assigned to that flow; otherwise, flows are read-only. * When copying a flow, assigned roles are removed, and the copy runs with either system roles or the initiating user's roles. ## Handling Missing Roles * If a flow references a role not present on the instance (e.g., removed or absent after moving between instances), the role's sysid is shown instead of its name. * Flows cannot be saved while they contain missing roles; to save, remove the missing role or add it back to the instance. ## Execution Details and Role Visibility * The roles a flow runs with can be viewed in the flow execution details under the "Run with role(s)" field. * The "Run As" field identifies the user who ran the flow. * Only flows running as the initiating user display assigned roles in execution details. ## Subflow Role Behavior * Subflows run with their own assigned roles and do not inherit roles from parent flows. * After a subflow completes, execution returns to the parent flow with the parent's roles restored, removing any special roles from the subflow. ## Access Control Considerations * Assigning roles to a flow does not guarantee access to all records or tables; roles are one part of Access Control Lists (ACLs). * If a flow lacks expected access, review the ACL rules for relevant tables and fields, as additional conditions may apply. Create flows and subflows that run with specific roles. Assigning roles enables you to create user-initiated flows that run with their own roles rather than the user's roles. ## Role selection {#flow-roles__section_orj_3ff_jlb} A flow runs as either the system user or as the user who initiates the session. You can only assign roles to flows that run as the user who initiates the session. When the flow runs as the system user, it runs with the system role, and individual role selection isn't available. For more information, see [Create a flow in Workflow Studio](https://servicenow-prod.fluidtopics.net/yY82uZapEVc3O5SdguStOA "Run a sequence of actions and flow logic when the trigger conditions occur."). You can assign multiple roles to a flow. Selecting new roles replaces the flow's original roles. If roles aren't selected, the flow runs with the roles of the user who initiates the session. The roles you can select for a flow depend on the roles you have and the application scope of the flow. Assign any roles you that have access to in a particular scope, except high-security roles. You can't assign the following roles to a flow: * admin * security_admin * application-specific admin roles, such as an application admin role for Human Resources. {#flow-roles__ul_wrt_3gf_jlb} ## Modified and copied flows {#flow-roles__section_btp_pff_jlb} Other users can modify and copy your flow. To modify a flow, a user must have the same roles as the flow. Users missing any of the roles assigned to the flow, sees the flow as read-only. When you copy a flow, the assigned roles are removed. The copied flow runs with either the system role or the roles of the user who initiated the session. ## Missing roles {#flow-roles__section_wh5_qff_jlb} Sometimes a flow refers to a role that is not on the instance. The missing role may have been removed or may not exist on the instance. Either situation can occur when moving a flow between instances. When a role is unavailable, the Run with role(s) field displays the sys_id of the role instead of its name. While the role is missing, you cannot save changes to the flow. To save flow changes, either remove the role from the flow or add it to the instance. ## Flow roles in execution details {#flow-roles__section_jbt_xgf_jlb} You can see the "Run with" roles for a flow by viewing the flow execution details. Use the Run As field to determine which user ran the flow. Only flows that ran as the initiating user can have roles assigned. These flows have a Run with role(s) field that displays the roles assigned to the flow. ## Subflow roles {#flow-roles__section_sly_4gf_jlb} Flows and subflows each run with their own roles. Subflows don't inherit roles from a parent flow. When flow execution returns to a parent flow from a child flow, any special roles associated with the child flow are removed. The parent continues execution with its own roles. ## Access control lists {#flow-roles__section_qd5_rff_jlb} Assigning a role to a flow doesn't guarantee that the flow can access a record or table. While roles are an important part of access control lists (ACLs), they are just one possible condition. If a flow cannot access the records you expect it to, review the record ACL rules for the table and fields. The ACL rules might require additional criteria to grant access. For more information, see [access control list rules](https://www.servicenow.com/docs/access?context=access-control-rules&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).