Flow roles

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
    • Summarize
    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 enable you to create flows and subflows that run using specific roles rather than the roles of the user initiating the flow. This functionality is available only for flows configured to run as the initiating user; flows running as the system user always run with the system role. Assigning roles to flows helps control permissions and execution context, improving security and operational precision.

    Show full answer Show less

    Role Selection and Management

    • You can assign multiple roles to a flow, but selecting new roles replaces any previously assigned roles.
    • If no roles are assigned, the flow runs with the roles of the user who started it.
    • Role assignment options depend on the roles you possess and the application scope of the flow.
    • Certain high-security roles are not assignable to flows, including admin, securityadmin, and application-specific admin roles.
    • When flows are copied, all assigned roles are removed, causing the copied flow to run either with the system role or the initiator’s roles.

    Modifying Flows and Role Restrictions

    • Users can modify flows only if they possess all roles assigned to that flow; otherwise, the flow is read-only for them.
    • If a flow references roles that do not exist on the instance (e.g., due to role removal or moving flows between instances), the flow shows the role's sysid instead of its name and cannot be saved until the role is restored or removed.

    Execution and Visibility

    • Execution details of a flow show the "Run with" roles, available only for flows running as the initiating user.
    • The "Run As" field indicates which user ran the flow, and the "Run with role(s)" field displays the roles assigned to the flow during execution.
    • Flows and subflows run with their own assigned roles; subflows do not inherit roles from parent flows, and role context reverts to the parent flow's roles once the subflow completes.

    Access Control Considerations

    Assigning roles to a flow does not automatically grant access to all records or tables. Roles are part of access control list (ACL) rules, but ACLs may include additional conditions. If a flow encounters access issues, review the ACL rules on the relevant tables and fields to ensure all necessary permissions and criteria are met.

    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

    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.

    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.

    Modified and copied flows

    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

    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

    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

    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

    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.