---
sourceDocument: Brazil Build workflows
sourceDocumentLink: https://www.servicenow.com/docs/r/build-workflows

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# User access to flows

# User access to Workflow Studio flows {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 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 User access to Workflow Studio flows

Administrators control user access to Workflow Studio flows by assigning specific roles or delegated development permissions.
These roles determine what features and content users can access, ranging from creating and editing flows to viewing execution details.
Application developers can also interact with Workflow Studio through APIs for flows, subflows, and actions.
Show full answer Show less  

## Access by User Role

Users gain access primarily through the **flowdesigner** role, which allows creating and editing flows. However, this role grants permissions equivalent to admin since Workflow Studio can run flows as the System user with unrestricted access. To provide more granular control, administrators can assign specific Workflow Studio roles tailored for tasks such as:

* **flowadmin:** Limited admin access to all flow, subflow, and action content.
* **flowdesignerscripting:** Permission to write inline scripts for input values.
* **flowoperator:** View flow execution details without editing capabilities.
* **flowreportviewer:** Access to flow reporting tables and reports.
* **triggerdesigner:** Create, edit, and delete flow triggers.
* **actiondesigner:** Create and edit actions with access to all actions regardless of scope.
* **actioncategorycreator:** Create categories for actions and subflows.
* **fdread and related read-only roles:** View-only access to flows, subflows, actions, and execution details without write permissions.

**Important:** Avoid assigning conflicting write and read-only roles to the same user to prevent access issues.

## Delegated Development Access

Administrators can assign delegated development permissions by creating an application and adding users as developers. This method controls access to advanced features typically restricted to admins, such as assigning roles, creating access controls, or scripting.

## Role-Based Content and Feature Access

Administrators can specify which user roles are required to access specific Workflow Studio content (flows, triggers, actions, subflows) through content filtering rules and definitions. Additionally, feature access controls allow specifying roles needed to interact with UI elements like saving, testing, activating flows, or copying code snippets. Both content and feature access management ensure users have appropriate permissions aligned with their responsibilities.

## API Access

Developers can use Workflow Studio APIs to interact programmatically with flows, subflows, and actions. Flow authors can configure flows to be client-callable, enabling integration with other ServiceNow applications or external systems.

## Practical Considerations

* Grant the **flowdesigner** role cautiously due to its broad access implications.
* Use specific roles to tailor access and limit risks associated with excessive permissions.
* Ensure users needing view-only access receive appropriate read-only roles to avoid unintended editing capabilities.
* Leverage delegated development to safely extend development capabilities without full admin privileges.
* Manage content and feature access systematically to maintain security and compliance within your workflows.  
Administrators can grant users access to Workflow Studio flows by assigning delegated development permissions or directly assigning a user role. Administrators can also specify which features and content a user can access based on user roles. Application developers can access Workflow Studio functionality through APIs for flows, subflows, and actions.

## Access by user role {#user-access-flow-designer__section_qhv_kzq_nnb}

Administrators can grant access to Workflow Studio flows 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 Workflow Studio can run flows as the System user, which has access to all tables and all database operations.

Administrators can also grant users one or more Workflow Studio roles to enable them to create flows and subflows, view flow execution details, and create actions.  
{#user-access-flow-designer__table_utq_v2r_nnb__entry__3}

| Role title \[name\] | Description | Contains Roles |
|-|-|-|
| flow_admin | Enables limited admin access to all Workflow Studio flow, subflow, and action content. | flow_designer, flow_operator, flow_write_enabled, action_designer, action_category_creator, action_write_enabled, flow_designer_scripting, connection_admin, flow_report_viewer |
| flow_designer | Enables you to launch the Workflow Studio flow design environment to create and edit flows and subflows. | flow_operator, trigger_designer |
| flow_designer_scripting | Enables someone with the flow_designer or action_designer role to set and modify input values by writing inline scripts. For information, see [Inline scripts](https://www.servicenow.com/docs/4uIbspkqLERs8ysjXh4fUA "Enable users with coding experience to write inline scripts that set and modify input values during the configuration of an action or flow. Use inline scripts to modify input values that require small format conversions, data transformations, or math operations."). | none |
| flow_operator | Enables you to view flow execution details, dashboards, and logs. Administrators can grant this role to users that want to be able to view flow results but not create, change, or test them. | none |
| flow_report_viewer | Enables you to view reports for Workflow Studio flow tables. For a list of relevant flow reporting tables, see [Flow execution details retention](https://www.servicenow.com/docs/u5lBwSuee5eYD3ijj4UjEA "Due to the large amount of data consumed by flow execution details, your instance uses data retention policies to delete this data after a set time period."). | none |
| trigger_designer | Enables you to launch Workflow Studio and create, edit, and delete a saved trigger. | none |
| action_designer | Enables you to launch the Workflow Studio action design environment to create and edit actions. Important: This role provides access to all actions regardless of their application scope. | none |
| action_category_creator | Enables someone with the action_designer role to create action categories for actions and subflows. | none |
| fd_read | Enables you to launch the Workflow Studio flow and action design environments to view the configuration and execution details of flows, subflows, and actions. Note: Read only roles are incompatible with roles that provide write access. Avoid granting the same user both a read only and a write access role. | fd_read_flows, fd_read_actions, fd_read_operations |
| fd_read_flows | Enables you to launch the Workflow Studio flow design environment to view the configuration and execution details of flows and subflows. Note: Read only roles are incompatible with roles that provide write access. Avoid granting the same user both a read only and a write access role. | fd_read_operations |
| fd_read_actions | Enables you to launch the Workflow Studio action design environment to view the configuration of actions. Note: Read only roles are incompatible with roles that provide write access. Avoid granting the same user both a read only and a write access role. | none |
| fd_read_operations | Enables you to view basic flow and action execution details. When reporting is enabled, you can only see basic execution details such as the runtime state and duration. If the reporting level generates additional details, you can't see them. Administrators can grant this role to users that only need to view basic execution results but not create, change, or test flows and actions. Note: Read only roles are incompatible with roles that provide write access. Avoid granting the same user both a read only and a write access role. | none |
| fd_read_operations_all | Enables you to view all generated flow and action execution details. When reporting is enabled, you can view all available execution details. You can only see as much detail as defined by the reporting level system property. Administrators can grant this role to users that need to view all flow results but not create, change, or test flows and actions. Note: Read only roles are incompatible with roles that provide write access. Avoid granting the same user both a read only and a write access role. | fd_read_operations |
[Table 1. Workflow Studio roles]

{#user-access-flow-designer__table_utq_v2r_nnb}  
Note:  
Some applications provide UI actions to view related flow or flow contexts. You need an application-specific user role to view such UI actions. For example, users require the itil or equivalent user role to view the Flow Context UI action available from Requested Item records.

## API access {#user-access-flow-designer__section_mlq_tzq_nnb}

Application developers can access Workflow Studio functionality through APIs for flows, subflows, and actions. Flow authors can enable individual flows, subflows, and actions to be client callable during design. For more information, see [API access to Workflow Studio flows](https://www.servicenow.com/docs/k2lwaKtB4HcbPQWISOaIsg "Application developers can access Workflow Studio functionality through APIs for flows, subflows, and actions. Flow authors can enable individual flows, subflows, and actions to be client callable during design.").

## Delegated development access {#user-access-flow-designer__section_zgg_xmy_1fb}

Administrators can grant users access to Workflow Studio flows by creating an application and assigning users as developers with the [delegated development](https://www.servicenow.com/docs/access?context=c_DelegatedDevelopment&version=brazil&pubname=brazil-application-development&ft:locale=en-US) 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. For more information, see [Developer permissions](https://www.servicenow.com/docs/access?context=developer-permissions&version=brazil&pubname=brazil-application-development&ft:locale=en-US).

## Role-based content filtering {#user-access-flow-designer__section_ijg_wcs_gtb}

Specify the user roles necessary to access Workflow Studio flow content. For example, flows, flow triggers, actions, and subflows. Manage content filtering by creating content definitions and content filtering rules. For more information, see [Content filtering for Workflow Studio flows](https://www.servicenow.com/docs/cM9i8Fx26V~PGVoLdTKf0w "Specify which content a user can access based on the user's role.").  
Note:  
Your users must have the flow_designer role to create and edit flows. You can specify the additional roles that a user must have to access particular features or content.

## Role-based feature access {#user-access-flow-designer__section_ivd_vzq_nnb}

Specify additional user roles necessary to access the UI elements of Workflow Studio flows. For example, specify a role to access the buttons to save, test, or activate a flow or to access the option to copy a code snippet. Manage feature access directly through the Feature Access List. For more information, see [Manage access to Workflow Studio flow features](https://www.servicenow.com/docs/Q0JnANX_xhnQPhI~vsX6wQ "Restrict access to individual Workflow Studio flow features by user role. Specify what additional roles a user must have to access an individual feature such as copy a flow.").  
Note:  
Your users must have the flow_designer role to create and edit flows. You can specify the additional roles that a user must have to access particular features or content.