Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions docs.json
Original file line number Diff line number Diff line change
Expand Up @@ -124,8 +124,14 @@
"pages": ["guides/reporting/bva"]
},
{
"group": "Sharing workflow",
"pages": ["guides/sharing/data-anonymization"]
"group": "Sharing & permissions",
"pages": [
"guides/sharing/permissions-overview",
"guides/sharing/adding-and-managing-users",
"guides/sharing/sharing-pages",
"guides/sharing/workspace-access-management",
"guides/sharing/permissions-reference"
]
}
]
}
Expand Down
88 changes: 88 additions & 0 deletions guides/sharing/adding-and-managing-users.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
title: "Adding & managing users"
description: "How to invite users to your workspace, assign and change roles, and create groups for bulk permission management."
---

## Adding users to your workspace

There are two ways to add users:

### From workspace settings

1. Go to **Settings > Users**.
2. Enter one or more email addresses (comma or space-separated).
3. Assign a role (Admin, Manager, Member, or Guest).
4. Click **Add**.

### From the Share menu

1. Open a page and click **Share**.
2. Type an email address in the search field.
3. If the email matches an existing workspace member, select them from the dropdown and assign an access level.
4. If the email doesn't match an existing member, you can invite them directly. They'll be added to the workspace and granted access to the resource.

<Note>Runway does not send email invites automatically when adding users through Settings. Share your workspace URL or specific page links with new users directly. When inviting via the Share menu, you can include an optional message with the invitation.</Note>

## Changing a user's role

1. Go to **Settings > Users**.
2. Find the user in the list.
3. Select a new role from the dropdown next to their name.

Changing a user's role updates their baseline permissions across the entire workspace. For example, changing someone from Manager to Member means they'll lose default access to content that isn't explicitly shared with them.

## Removing users

1. Go to **Settings > Users**.
2. Find the user you want to remove.
3. Click the remove button next to their name.

Removing a user revokes all of their access to the workspace and its content.

## User groups

Groups are custom collections of users that make it easy to manage permissions in bulk. Instead of sharing a page with 10 people individually, you can create a group and share with the group.

<Note>Groups are different from roles. Roles (Admin, Manager, Member, Guest) are system-defined and determine baseline capabilities. Groups are custom collections you create purely for sharing convenience.</Note>

### Creating a group

1. Open **Workspace Access** (Settings > Workspace Access, or via the Share menu > Manage groups).
2. Click **Create group**.
3. Name the group (e.g., "Finance Team", "Board Members").
4. Add members by searching for users.

### Adding and removing members

1. Open **Workspace Access** and navigate to the **Group** tab.
2. Select the group you want to modify.
3. Add new members by searching for users, or remove existing members.

### Granting a group access to resources

Once a group exists, you can share resources with it just like you would with an individual user:

1. Open the Share menu on any page or resource.
2. Search for the group name.
3. Choose an access level.

All members of the group receive the specified access. When you add new members to the group later, they automatically get the same access.

### Deleting a group

1. Open **Workspace Access** and navigate to the **Group** tab.
2. Select the group.
3. Click **Delete group**.

Deleting a group removes all access that was granted through the group. Individual members retain any access that was granted to them directly or through other groups/roles.

## Default access by role

Understanding what each role gets by default — before any explicit sharing — helps you plan your workspace permissions:

| Role | Default content access | Key restrictions |
|---|---|---|
| **Admin** | Full access to all content | None — Admins have unrestricted access |
| **Manager** | Full access to most content | Cannot merge scenarios, delete sections, or manage workspace settings |
| **Member** | No default content access — must be explicitly shared | Cannot create pages, models, or databases |
| **Guest** | No default content access — must be explicitly shared | View-only access; cannot edit or create content |
5 changes: 0 additions & 5 deletions guides/sharing/data-anonymization.mdx

This file was deleted.

118 changes: 118 additions & 0 deletions guides/sharing/permissions-overview.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,118 @@
---
title: "Permissions overview"
description: "Runway uses a layered permissions system: workspace roles set your baseline access, and resource-level permissions let you fine-tune who can see and edit specific content."
---

## Workspace roles

Every user in a workspace is assigned exactly one role. Roles determine what a user can do by default before any resource-level sharing is configured.

### Admin

Full access to all content and workspace settings. Admins can configure the model, integrations, and all workspace-level settings. They can also manage permissions and access for all users.

### Manager

Can trace and edit models, create scenarios, and access shared information. Managers have broad access to most content by default, but cannot merge scenarios, delete sections, or manage workspace settings.

### Member

Can trace models, create scenarios, and access content that has been explicitly shared with them. Members cannot create pages, models, or databases on their own.

### Guest

Can view pages and data that have been explicitly shared with them. Guests have view-only access and cannot create or edit content.

## Access levels

When you share a resource with someone, you choose an access level that defines what they can do with it. There are four access levels:

| Access Level | What it means |
|---|---|
| **Full access** | Can edit, delete, and share the resource |
| **Can edit** | Can modify content but cannot share or delete |
| **Can view** | Read-only access |
| **No access** | Resource is hidden from the user |

<Note>Not all resource types support all access levels. For example, Sections support Full access, Can view, and No access — but not Can edit. See [Access levels by resource type](/guides/sharing/permissions-reference#access-levels-by-resource-type) for details.</Note>

## Special capabilities

Some actions have their own permission toggles beyond the standard access levels:

- **Can merge** — Merge a scenario back into the main scenario (Scenarios only).
- **Can drill in** — See the inputs behind a calculated value (Blocks only).

These are configured separately in the Share menu. For details on who has these by default and how to configure them, see [Special capabilities](/guides/sharing/permissions-reference#special-capabilities) in the Permissions Reference.

## Who you can share with

You can grant access to three types of entities:

- **Individual users** — Workspace members identified by email address.
- **Roles** — System roles (Admin, Manager, Member, Guest). When you grant access to a role, all users with that role receive the specified access.
- **Groups** — Custom collections of users that you create for bulk permission management. For example, you might create a "Finance Team" group and share all finance-related pages with that group at once.

## Permission inheritance

By default, permissions flow down from parent to child:

```
Workspace defaults → Sections → Pages → Blocks
```

This means when you set permissions on a Section, all Pages within that Section inherit those permissions. Similarly, all Blocks on a Page inherit the Page's permissions.

### Customizing permissions on a specific resource

You can override the inherited permissions for any individual resource. When you do this, the resource becomes **unlinked** from its parent's settings — it has its own independent permissions that won't change when the parent's permissions change.

### Reverting to inherited permissions

If you've customized a resource's permissions and want to go back to the defaults, you can **relink** it. This removes the custom settings and the resource goes back to inheriting from its parent.

### Example

Suppose your workspace has a Section called "Finance" with Full access for Managers. Inside it, there's a page called "Compensation Planning" that you want to restrict.

1. Open the Share menu on the "Compensation Planning" page.
2. Change the Manager role from "Full access" to "Can view".
3. Confirm "Change and unlink".

Now that page has its own permissions — Managers can view but not edit — while all other pages in the Finance section still inherit Full access for Managers.

Later, if you want to revert, click the **Relink** option on the page's Share menu. The page goes back to inheriting the Section's permissions.

## Per-scenario permissions

Resources in Runway can have different permissions across different scenarios. For example, a user might have "Can edit" access to a page in Scenario A, but "No access" in Scenario B.

This allows teams to control who can see and modify data in different planning scenarios — useful when different teams are working on separate forecasts or when you want to restrict access to sensitive what-if analyses.

Most resource types — including Pages, Sections, and Blocks — support per-scenario permissions. A small number of resource types (like Scenarios themselves, integrations, and workspace-level settings) have permissions that apply globally rather than per-scenario.

## Role comparison matrix

This table summarizes the most important capabilities for each role:

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| View all pages, models, databases | Yes (default) | Yes (default) | Only if shared | Only if shared |
| Edit pages | Yes | Yes | If granted | No |
| Create pages, models, databases | Yes | Yes | No | No |
| Create scenarios | Yes | Yes | Yes | No |
| Merge scenarios | Yes | No | No | No |
| Delete sections | Yes | No | No | No |
| Manage workspace settings | Yes | No | No | No |
| Configure integrations | Yes | Yes (create only) | No | No |
| Manage share/access settings | Yes | No | No | No |
| Update last close date | Yes | No | No | No |
| View driver drill-in details | Yes | Yes | Yes | No |

For a complete breakdown, see [Permissions reference](/guides/sharing/permissions-reference).

## Access rules by resource type

Not all resource types support the same access levels. For example, Sections don't have a "Can edit" level, and Blocks have a "Can drill in" option that other resources don't.

For the complete breakdown, see the [Access levels by resource type](/guides/sharing/permissions-reference#access-levels-by-resource-type) table in the Permissions Reference.
110 changes: 110 additions & 0 deletions guides/sharing/permissions-reference.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,110 @@
---
title: "Permissions reference"
description: "Detailed reference tables for every role, resource type, and capability in Runway's permissions system."
---

## Complete role capabilities matrix

### Pages

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| View all pages | Yes | Yes (default) | Only if shared | Only if shared |
| Edit pages | Yes | Yes | If granted | No |
| Create pages | Yes | Yes | No | No |
| Delete pages | Yes | Yes | No | No |
| Share pages | Yes | Yes | No | No |

### Sections

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| View all sections | Yes | Yes (default) | Only if shared | Only if shared |
| Create sections | Yes | Yes | No | No |
| Delete sections | Yes | No | No | No |

### Scenarios

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| View Main Scenario | Yes | Yes | Yes | Only if shared |
| View other scenarios | Yes | Yes (if shared/created) | If shared | Only if shared |
| Create scenarios | Yes | Yes | Yes | No |
| Merge scenarios | Yes | No | No | No |

### Databases

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| View databases | Yes | Yes (default) | Only if shared | Only if shared |
| Edit databases | Yes | Yes | If granted | No |
| Create databases | Yes | Yes | No | No |

### Models

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| View models | Yes | Yes (default) | Only if shared | Only if shared |
| Edit models | Yes | Yes | If granted | No |
| Create models | Yes | Yes | No | No |

### Integrations

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| Create integrations | Yes | Yes | No | No |
| View integration results | Yes | No (default) | No | No |

### Workspace settings

| Capability | Admin | Manager | Member | Guest |
|---|---|---|---|---|
| Manage workspace settings | Yes | No | No | No |
| Manage access/permissions | Yes | No | No | No |
| Manage data anonymization | Yes | No | No | No |

Check warning on line 64 in guides/sharing/permissions-reference.mdx

View check run for this annotation

Mintlify / Mintlify Validation (runway-5055a12e) - vale-spellcheck

guides/sharing/permissions-reference.mdx#L64

Did you really mean 'anonymization'?
| Update last close date | Yes | No | No | No |

## Access levels by resource type

| Resource Type | Available Access Levels | Notes |
|---|---|---|
| Page | Full access, Can edit, Can view, No access | — |
| Section | Full access, Can view, No access | No "Can edit" level |
| Block | Full access, Can view, Can drill in, No access | Drill-in controls whether users can see the inputs behind calculated values |
| Scenario | Full access, Can view, Can merge, No access | Merge is a separate capability |
| Database column | Can view, No access | Used for restricting sensitive data |
| Integration | Full access, Can edit, Can view, No access | Managers can create but cannot view by default |

## Access level definitions

| Access Level | Description |
|---|---|
| **Full access** | Can edit, delete, and share the resource. Includes all capabilities. |
| **Can edit** | Can modify the resource's content. Cannot share, delete, or manage access settings. |
| **Can view** | Read-only access. Can see the resource but cannot make changes. |
| **No access** | Resource is completely hidden. The user cannot see it in the sidebar or access it via URL. |

## Special capabilities

### Can merge (Scenarios only)

The ability to merge a scenario back into the Main Scenario. This is a high-impact action that applies the scenario's changes to the workspace's primary data.

Check warning on line 91 in guides/sharing/permissions-reference.mdx

View check run for this annotation

Mintlify / Mintlify Validation (runway-5055a12e) - vale-spellcheck

guides/sharing/permissions-reference.mdx#L91

Did you really mean 'workspace's'?

- **Who has it by default:** Admins only.
- **How to configure:** Open the Share menu on a scenario and toggle the "Can merge" capability for specific users, groups, or roles.

### Can drill in (Blocks only)

The ability to see the inputs and formula behind a calculated value in a block. When drill-in is enabled, users can click on a cell to see what drives its value.

- **Who has it by default:** Admins, Managers, and Members.
- **How to configure:** Open the Share menu on a block and toggle the "Can drill in" capability.
- **Note:** Guests never have drill-in access.

### Integration permissions

Integrations have a unique permission model:

- **Create:** Admins and Managers can create integrations.
- **View results:** Only Admins can view integration results by default. Managers must be explicitly granted access.
- This distinction exists because integration data may contain sensitive information from connected systems.
Loading