From 5212e955d0fe01f80da6bcc5b8b16f294e928dbb Mon Sep 17 00:00:00 2001 From: Rishi Date: Fri, 13 Mar 2026 13:07:51 -0400 Subject: [PATCH] Add permissions v2 documentation Replace the old sharing workflow docs with a comprehensive 5-page permissions section covering roles, access levels, inheritance, sharing workflows, workspace access management, and reference tables. Co-Authored-By: Claude Opus 4.6 --- docs.json | 10 +- guides/sharing/adding-and-managing-users.mdx | 88 +++++++++++++ guides/sharing/data-anonymization.mdx | 5 - guides/sharing/permissions-overview.mdx | 118 ++++++++++++++++++ guides/sharing/permissions-reference.mdx | 110 ++++++++++++++++ guides/sharing/sharing-pages.mdx | 88 +++++++++++++ .../sharing/workspace-access-management.mdx | 97 ++++++++++++++ 7 files changed, 509 insertions(+), 7 deletions(-) create mode 100644 guides/sharing/adding-and-managing-users.mdx delete mode 100644 guides/sharing/data-anonymization.mdx create mode 100644 guides/sharing/permissions-overview.mdx create mode 100644 guides/sharing/permissions-reference.mdx create mode 100644 guides/sharing/sharing-pages.mdx create mode 100644 guides/sharing/workspace-access-management.mdx diff --git a/docs.json b/docs.json index b7901a6..8daa0c3 100644 --- a/docs.json +++ b/docs.json @@ -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" + ] } ] } diff --git a/guides/sharing/adding-and-managing-users.mdx b/guides/sharing/adding-and-managing-users.mdx new file mode 100644 index 0000000..355941c --- /dev/null +++ b/guides/sharing/adding-and-managing-users.mdx @@ -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. + +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. + +## 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. + +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. + +### 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 | diff --git a/guides/sharing/data-anonymization.mdx b/guides/sharing/data-anonymization.mdx deleted file mode 100644 index 69a9da4..0000000 --- a/guides/sharing/data-anonymization.mdx +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: 'Data anonymization' -description: 'Description of your new file.' ---- - diff --git a/guides/sharing/permissions-overview.mdx b/guides/sharing/permissions-overview.mdx new file mode 100644 index 0000000..e4e14c0 --- /dev/null +++ b/guides/sharing/permissions-overview.mdx @@ -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 | + +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. + +## 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. diff --git a/guides/sharing/permissions-reference.mdx b/guides/sharing/permissions-reference.mdx new file mode 100644 index 0000000..fcdaaa6 --- /dev/null +++ b/guides/sharing/permissions-reference.mdx @@ -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 | +| 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. + +- **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. diff --git a/guides/sharing/sharing-pages.mdx b/guides/sharing/sharing-pages.mdx new file mode 100644 index 0000000..029f0c7 --- /dev/null +++ b/guides/sharing/sharing-pages.mdx @@ -0,0 +1,88 @@ +--- +title: "Sharing pages" +description: "How to share content with teammates and create links for external stakeholders." +--- + +## The Share menu + +Click **Share** on any page to open the Share menu. The Share menu has two tabs: + +- **People** — Share with workspace members, roles, or groups +- **Links** — Create share links for external access + +## Sharing with workspace members + +Use the **People** tab to share content with people who are already in your workspace. + +1. Click **Share** on the page. +2. In the search field, type a user's name, email, a role name, or a group name. +3. Select the entity from the dropdown. +4. Choose an access level: **Full access**, **Can edit**, **Can view**, or **No access**. +5. If the resource supports per-scenario permissions, choose which scenarios the person gets access to. + +Changes take effect immediately. + +### What each access level means on a page + +| Access Level | What you can do | +|---|---| +| **Full access** | Edit, delete, share, and manage access on the page | +| **Can edit** | Edit page content, but cannot share or delete the page | +| **Can view** | View the page, but cannot make changes | +| **No access** | Page is hidden from the sidebar and inaccessible via URL | + +For a full breakdown of access levels across all resource types, see [Permissions reference](/guides/sharing/permissions-reference). + +## Sharing with external users (share links) + +Share links let you give access to people outside your workspace — investors, board members, or external partners. + +### Creating a share link + +1. Click **Share** on the page and go to the **Links** tab. +2. Click the **+** button to create a new link. +3. Choose the access level for the link. +4. If applicable, choose which scenarios the link grants access to. + +### Security options + +Each share link has optional security settings: + +- **Require password** — Recipients must enter a password before they can view the content. +- **Require login** — Recipients must log in with a Runway account. Without this, anyone with the link can view the content anonymously. + +### How share links work + +When someone uses a share link, they join the workspace as a Guest with the access level you specified on the link. + +### Deleting a share link + +Deleting a share link immediately revokes access for anyone who joined through it. To delete a link: + +1. Open the Share menu and go to the **Links** tab. +2. Click the delete button next to the link you want to remove. + +## Inviting new users via the Share menu + +If you type an email that doesn't match an existing workspace member, you can invite them directly from the Share menu: + +1. Type the email address in the search field. +2. Select the option to invite them. +3. Optionally include a message with the invitation. +4. Choose the access level for the resource. + +The invitee receives an email and is assigned a role when they join (defaults to Guest if no role is specified). + +## Customizing inherited permissions + +When you share a Section, all Pages inside it inherit those permissions automatically (see [Permission inheritance](/guides/sharing/permissions-overview#permission-inheritance) for the full explanation). If you need different permissions on a specific Page: + +1. Open the Share menu on that Page. +2. Change the permissions as needed. +3. Confirm **Change and unlink**. + +The page now has its own independent permissions. A banner will appear: + +> "Share settings on this page are unlinked from the default access settings" + +To revert, open the Share menu and click **Relink** — the page goes back to inheriting from the Section. diff --git a/guides/sharing/workspace-access-management.mdx b/guides/sharing/workspace-access-management.mdx new file mode 100644 index 0000000..b2a2eb9 --- /dev/null +++ b/guides/sharing/workspace-access-management.mdx @@ -0,0 +1,97 @@ +--- +title: "Workspace access management" +description: "A full-screen interface for Admins to manage permissions across the entire workspace." +--- + +## Opening Workspace Access + +Go to **Settings > Workspace Access** to open the full-screen management view. + +Workspace Access is available to Admins only. + +## Navigating the Workspace Access view + +The left sidebar has tabs that give you different perspectives on your workspace's permissions: + +| Tab | What it shows | +|---|---| +| **User** | All users and their access across resources | +| **Group** | Custom groups and their access | +| **Role** | Access granted per system role | +| **Scenario** | Who has access to each scenario | +| **Section** | Who has access to each section | +| **Page** | Who has access to each page | +| **Other Settings** | Workspace-level permission settings | + +## View by User + +See every user in the workspace along with their role, group memberships, and per-resource access across all scenarios. + +From this view you can: + +- Change a user's role +- Adjust their access to specific resources +- See which groups they belong to +- Understand their effective permissions across the workspace + +## View by Group + +See all custom groups in the workspace. + +From this view you can: + +- Create new groups +- Add or remove group members +- See what resources each group has access to +- Adjust group-level access to specific resources + +## View by Role + +See what access is granted to each system role (Admin, Manager, Member, Guest) across all resources. This is useful for understanding the baseline permissions before any individual or group-level customization. + +## View by Scenario, Section, or Page + +These tabs let you start from a specific resource and see who has access to it. From any resource view you can: + +- See which users, groups, and roles have access +- Adjust access levels for individual users, groups, or roles +- Create share links for the resource + +## Other Settings + +### Sidebar permission inheritance + +This setting controls whether permissions flow down from parent resources to child resources. + +- **When enabled (default):** Permissions flow from Sections → Pages → Blocks. Sharing a Section automatically shares all of its Pages. +- **When disabled:** Each resource must have its permissions managed independently. Sharing a Section does not affect the Pages inside it. + +## Restricting access to sensitive data + +Admins can anonymize specific database columns to hide sensitive information like salaries, personal details, or confidential metrics. + +### How anonymization works + +When a database column is anonymized, non-Admin users see `***` instead of the actual values. This applies everywhere the column appears in the workspace. + +### Setting up anonymization + +1. Go to **Workspace Access > Other Settings** (or the relevant database settings). +2. Select the database columns you want to anonymize. +3. Save your changes. + +### Selectively revealing anonymized data + +In some cases, you may want specific users to see anonymized data on a particular page — for example, showing a manager their direct reports' compensation. Admins can reveal anonymized data within a specific block: + +1. Add the database as a block on a page. +2. Apply filters to show only the relevant rows (e.g., filter to a specific team). +3. Enable **Reveal hidden data in this block**. + +When revealed: + +- Users see the actual values only within that specific block. +- Filters and columns are locked so users cannot browse to other data. +- The reveal only applies to the specific block — the data remains anonymized everywhere else. + +Anonymization only works with database blocks and database columns. It does not apply to data displayed in charts or other block types.