Permissions in Workflows and Requests

Overview

Permissions control who can create workflows, start requests, and what actions they can take on requests. This guide explains how permissions work.

Permission Levels

Workflow-Level Permissions

Workflow permissions define who can start requests from a workflow. They apply to the workflow template and are inherited by requests created from it.

Available Actions:

• Start — Create new requests from this workflow
• View — View requests created from this workflow
• Comment — View and comment on requests
• Edit — Edit requests and update settings

Request-Level Permissions

Request-level permissions control access to specific requests. They can be set individually or inherited from the workflow.

Who Gets Permissions Automatically:

• Requesters — Can view and manage requests they created
• Approvers — Can view, comment, and approve requests they're assigned to
• Signers — Can view and sign requests they're assigned to

Permission Assignment

Permissions can be assigned to:

1. Individual Users — Specific people
2. Groups — All members of a group
3. Roles — Approvers, Signers, and Requesters get permissions automatically

How Permission Checking Works

When determining access, the system checks in this order:

1. User-level permissions — Directly assigned to the user
2. Group-level permissions — From groups the user belongs to
3. Role-based permissions — From being an Approver, Signer, or Requester
4. Admin/Designer access — Admins and designers have full access to their company's workflows and requests

If any check grants permission, the user has access.

Starting Requests

To create a request from a workflow, you need a workflow-level permission with one of these actions:

• start  
• edit   (includes start)
• start_and_view_own   (can only view your own requests)

Viewing Requests

To view a request, you need permission with one of these actions:

• view  
• comment  
• start  
• edit  
• start_and_view_own   (only for requests you created)
• Being the Requester, an assigned Approver, or an assigned Signer

Commenting on Requests

To comment, you need permission with one of these actions:

• comment  
• start  
• edit  
• Being an assigned Approver or Signer

Editing Requests

To edit a request, you need permission with:

• edit   action, OR
• Being an admin or designer

Common Scenarios

Scenario 1: Starting a New Request

• Needed: Workflow-level permission with start   or edit  
• Example: Sarah has start   permission on the "Custom NDA" workflow, so she can create requests from it.

Scenario 2: Viewing a Request You Didn't Create

• Needed: Request-level permission with view  , comment  , or edit  , OR being assigned as an Approver or Signer
• Example: John is assigned as an Approver on a request, so he can view it even without explicit permissions.

Scenario 3: Editing Someone Else's Request

• Needed: edit   permission on the request
• Example: Maria has edit   permission on a specific request, so she can update it even though she didn't create it.

Scenario 4: Group-Based Access

• Needed: Permission assigned to a group you belong to
• Example: The "Legal Team" group has view   permission on a workflow, so all members can view requests from that workflow.

Permission Inheritance

1. Workflow permissions → Requests inherit from their workflow
2. Group permissions → Users inherit from their groups
3. Role permissions → Automatically granted based on participation

Best Practices

1. Use workflow-level permissions for broad access across all requests from a workflow
2. Use request-level permissions for specific access to individual requests
3. Use groups when multiple users need the same access
4. Approvers and Signers automatically get appropriate permissions — no need to assign separately
5. Requesters automatically get access to their own requests
6. Use the Everyone group to assign permissions to auto-provisioned users. See description below.

SSO Auto-Provisioning: Granting New Users Request Access Automatically

If your company uses SSO auto-provisioning, the recommended way to let all new users start and view workflow requests is to use the Everyone group.

Why this works

The Everyone group is dynamic and grows automatically as users join.

Instead of assigning permissions user-by-user, assign workflow permissions once to Everyone and all current/future users inherit access.

What to configure

For each workflow, add a permission for Everyone with one of these actions:

• start_and_view_own : users can start requests and view only requests they created
• start : users can start requests and (based on your permission model) may have broader visibility

Recommended default

For most teams, use start_and_view_own on Everyone to give broad self-service request creation while limiting visibility to each requester’s own requests.

Workspace note (if applicable)

If your account uses workspaces, users must also be added to the relevant workspace.

Once they are workspace members, they are included in that workspace’s Everyone group and receive the configured permissions.

Troubleshooting

Can't start a request?

• Check if you have workflow-level start   or edit   permission
• Verify the workflow is published

Can't view a request?

• Check if you have request-level view  , comment  , or edit   permission
• Verify if you're the Requester, an assigned Approver, or an assigned Signer
• Check if you're in a group with permissions

Can't edit a request?

• Check if you have edit   permission on the request
• If you're the Requester, you could have edit access to your own requests if the workflow has been configured to enable that
• However, requesters can still:
  • Cancel their own requests (if in progress)
  • Upload signed agreements for their own requests

If a newly provisioned user can’t start or view requests:

• Confirm they are in Everyone
• Confirm Everyone has workflow permission on the target workflow
• Confirm workflow is published
• If using workspaces, confirm the user has workspace membership