> ## Documentation Index
> Fetch the complete documentation index at: https://klarity.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Fine-Grained Access Control of Process Index
> Control who can see and work on each value stream in your process index using Teams.
export const NeedHelp = () =>
Need help? Use the in-app chat — click the chat bubble in the bottom-right corner of Klarity Architect (staffed 24×5) — or email support@klarity.ai.
;
**Need Fine-Grained Access Control turned on?** It's enabled per workspace — reach out to your Klarity Value Delivery team member and they'll get it enabled for you.
## What Fine-Grained Access Control is
Until now, the only access model in the process index was your workspace role. That worked well for separating viewers and contributors, but it treated the process index as a single, shared surface: any Contributor or Workspace Admin — the majority of users — could see and act on **every** value stream in the workspace.
Fine-Grained Access Control (FGA) adds a second, sharper layer on top of your workspace role. You can now decide, **per value stream** — a top-level (L1) node in your [process index](/docs/user-docs/structure/process-index-deeper-dive) — which Teams can see it and what they can do with it.
Your process index is the source of truth that Klarity's agents — Companion, Advisor etc. — reason over. Deciding who shapes each value stream is what lets you **rely on that source of truth** — and stand behind everything built on top of it.
**With FGA you can:**
* **Keep a clear line of sight into who has access to what.** Access to each value stream is explicit, reviewable, and easy to confirm at any time — so you always know exactly who can see and shape your process index, and can move forward on it with confidence.
* **Keep the right people focused on the right work.** Scope each value stream to the Teams that own or contribute to it, so people aren't wading through processes that aren't theirs — and contributions land where they belong.
* **Get more from what your process index produces.** Because the right Teams are the ones shaping each value stream, the insights Klarity's agents, Advisor, and reports generate downstream reflect the right people's work — so you can lean on those outputs with even more confidence.
* **Protect sensitive information.** Restrict confidential value streams — compensation, legal, M\&A, security runbooks — so only the Teams that should see them can.
Everything below explains how it works, when to reach for it, how to set it up, and what to keep in mind as you go.
## When to use Fine-Grained Access Control
A few needs can look similar but are best solved in different ways. Use this to confirm FGA is the right tool for what you're trying to do before you set anything up — and to point you to another feature where it will serve you better.
**In short:** FGA is the right tool when you need to control *who can see and act on which value streams*. For routing *who contributes where*, start with the Context Store; use the Basic Contributor role to remove process index access entirely.
**Want to hide the process index from someone entirely? → [Basic Contributor role](/docs/user-docs/admin/add-a-user-to-your-workspace#user-roles).** Basic Contributors have no process index access at all, with or without FGA. This is a Workspace-level role, not FGA.
**Want to show, hide, or set different *levels* of access across parts of the process index? → FGA.** Grant each Team the level it needs, per value stream. Common shapes this takes:
* **"Not everyone should see everything."** Restrict sensitive value streams — HR, legal, compensation, security runbooks — so only certain groups can see them.
* **"The right people should own the right work."** Keep a value stream visible broadly, but let only its owning Team change it: *Everyone → Can view*, owning Team → *Can manage*.
**Want to route different Teams to contribute to different parts of the process index? → Context Store and FGA.**
* The [Context Store](/docs/user-docs/advanced/tailoring-for-non-standard-use-cases) is how you direct which Teams' work feeds which parts of the process index. It's the preferred path because routing often calls for more intelligent, nuanced customization than access levels alone can express — the kind of judgment AI can handle far better than a fixed permission on a value stream.
* FGA can help by controlling contribution at the value stream level — but doing so may require reorganizing your process index so Teams line up with L1 value streams (see [Structuring your process index](#structuring-your-process-index-for-access-control)).
* Need help? Reach out to your Value Delivery team, who can connect you with the Applied AI team to get the most out of your [Context Store](/docs/user-docs/advanced/refining-the-context-store).
## Before you start
FGA is built on **Teams**. Access is always granted to a Team, never to an individual — so before you can restrict a value stream, the relevant Teams need to exist.
### Teams, in brief
A **Team** is a named group of users in your workspace. Teams are the unit you grant access to.
* **Teams are flat.** There's no nesting or hierarchy — a Team is a simple, named group.
* **A user can belong to many Teams.** Someone can be on both `Finance` and `Deal Desk`, and their access is the *most permissive* of everything they're granted (see [Highest access wins](#highest-access-wins)).
* **Every Team can have a Team owner.** Team owners manage the Team's membership — who's in and who's out.
* **"Everyone at \[Workspace]" is a built-in Team.** Every workspace has a default Team containing all members. You'll use it to grant broad, open access to a value stream.
### Setting up your Teams
Go to **Settings → Teams**.
Select **Create team** and name it after how people actually work (`Revenue Operations`, `Payroll`, `Security`).
Search for people by name or email and add them. A user can be on as many Teams as needed.
Optionally assign one or more **Team owners** to keep membership current.
Give the Team a distinct **icon** — it appears next to the Team name when you manage access from the process index, making Teams quick to spot and reference at a glance.
Aim to model Teams on the groups that genuinely own or contribute to bodies of work, not on your org chart's every box. A handful of well-scoped Teams is far easier to reason about than dozens of overlapping ones.
### How FGA relates to your workspace roles
FGA doesn't replace [workspace roles](/docs/user-docs/admin/add-a-user-to-your-workspace) — it works with them. Your role sets the **ceiling**; FGA decides **which value streams** you reach within it.
* **Basic Contributors** never have process index access, with or without FGA. This is unchanged.
* **Viewers** are capped at view. Even if a Team grants them a higher level, a Viewer can only view.
* **Contributors** and **Workspace Admins** get whatever level their Teams are granted, up to their role ceiling.
* **Workspace Admins are still subject to FGA.** Admins do **not** automatically see restricted value streams. A restricted stream the admin's Teams aren't on stays hidden from them, exactly like anyone else. On value streams they *can* see, admins can always manage access.
## How to set up FGA on a value stream
**Prerequisite:** the Teams you want to grant access to already exist (see [Setting up your Teams](#setting-up-your-teams)).
In the process index, find the top-level (L1) node you want to control.
From the row menu, choose **Manage access**. (If you can see it but not manage it, this reads **View access** instead.)
* Choose **Open** to give the whole workspace a baseline (then pick Can manage / contribute / view for *Everyone at \[Workspace]*), or
* Choose **Restricted** to hide the value stream from everyone except the Teams you add.
Add each relevant Team and set its level. Remember at least one Team must have **Can manage**.
Klarity shows a summary of pending changes. Save to apply.
**Who can do this?** Workspace Admins, and anyone on a Team with **Can manage** on that value stream. Everyone else sees a read-only **View access** modal.
### How access works
Teams and levels are the setup; this is how permissions actually resolve once they're in place. Expand any topic:
Two things help you confirm access is set the way you intend:
* **"What can this Team do?"** — the **ⓘ** icon next to a Team shows its effective capabilities, including any limits imposed by members' workspace roles.
* **"What permissions do I have?"** — a link in the access modal that spells out your own effective access on this value stream and where it comes from. Useful when you're not sure why you can (or can't) do something.
On any value stream, a Team can be granted one of three levels:
| Level | What it means |
| ------------------ | -------------------------------------------------------------------------------------------- |
| **Can manage** | Full control: view, contribute, move, delete, and change who has access to the value stream. |
| **Can contribute** | View and edit the processes in the value stream, but cannot change access. |
| **Can view** | Read-only. Can see the processes but cannot edit them or change access. |
Every value stream must always have **at least one Team with Can manage** — this guarantees someone can always administer it. Klarity prevents you from removing the last managing Team.
To see or change these levels, go to the value stream in the process index and click its **Access** column to open access. Alternatively, open the **overflow menu (⋯)** on the right of the value stream's row and choose **Manage access**.
Each level maps to a specific set of capabilities (running interviews, using Companion, exporting, and so on). In the app, the **ⓘ** icon next to any level shows exactly what it allows.
Every value stream has a **General access** setting with two modes:
* **Open** — the *Everyone at \[Workspace]* Team is granted a level (Can manage, Can contribute, or Can view). Everyone in the workspace gets at least that level, subject to their role.
* **Restricted** — the value stream is granted only to the specific Teams you add, and is **completely hidden** from everyone else — it disappears from their process index entirely, along with everything inside it.
On top of General access, you add **Teams with access** — specific Teams, each at their own level. This is how you layer targeted access over (or instead of) open access.
Because a person can be on multiple Teams, and General access applies to everyone, a user often qualifies for a value stream through more than one grant. **The most permissive one always wins.**
*Example 1.* A value stream is Open with *Everyone → Can view*, and you add *Accounting → Can contribute*. A user on the Accounting team resolves to **Can contribute** (the higher of the two). Everyone else stays at Can view.
*Example 2.* A value stream is Open with *Everyone → Can manage*, and you add *Accounting → Can view*. A user who's on both the Everyone team and Accounting still resolves to **Can manage** — the more permissive grant wins, so the narrower Accounting grant doesn't pull them *down*. To actually limit Accounting to view-only, you'd lower the *Everyone* level (for instance, *Everyone → Can view*) and grant the Teams that should do more a higher level.
This is also the pattern for a very common setup: set *Everyone → Can view* so the whole workspace can read a value stream, then grant *Can contribute* or *Can manage* to just the Teams that actively work in it. Broad visibility, tight write access.
Access resolution is additive, never subtractive — a grant can only raise a user's level, never lower it. Feel free to experiment with combinations of General access and Team grants to find what fits your organization, and set each value stream accordingly.
* **Processes** in the value stream, at every level beneath the L1 node, inherit the value stream's access.
* **Artifacts linked to a process** — related files, or documents generated from a process — are bound by the same access as the process they're linked to.
* **Artifacts uploaded directly to the Library** (not linked to any process) are **not** governed by FGA today. If a file needs FGA protection, link it to a process.
FGA isn't just a UI filter. Every way Klarity touches the process index respects it:
* The **[Interviewer](/docs/user-docs/discover/capturing-current-state)** and **[Companion](/docs/user-docs/discover/running-your-first-companion-session)** can only capture into processes you can contribute to.
* The **[Advisor](/docs/user-docs/improve/advisor-analyze-processes)** and **[global AI chat](/docs/user-docs/improve/using-ai-chat)** only reason over value streams you can view.
* **File-upload operations** and the **[MCP tools](https://developers.klarity.ai)** are all bound by the same permissions.
If you can't see a value stream, neither can the agents acting on your behalf.
## Why access is set at the value stream level
In this first version, access is applied at the **value stream (L1) level** — the top-level nodes of your process index. Here's the thinking behind it.
* Klarity's agents — the Interviewer, Companion, Advisor, and the rest — read from and write to your process index on your behalf.
* At the value stream level, we're confident these agents reliably respect the access boundaries you set.
* We're actively extending that same reliability to deeper levels of the hierarchy, and as the underlying models continue to improve, access control will follow them down.
* Starting at the value stream level lets you get real value today, on a foundation the deeper levels build directly on top of — with no re-work when they arrive.
## Structuring your process index for access control
Because this first version controls access at the value stream (L1) level, the shape of your process index matters. A little restructuring up front gives you clean, defensible access boundaries — and, importantly, **no additional restructuring will be needed when deeper-level controls arrive.** What you set up now is the foundation they build on.
There are three patterns, and they combine freely.
The simplest move, and a good default. Keep a value stream visible to the whole workspace, but let only the owning Teams change it.
* Set **General access → Open, Everyone → Can view.**
* Grant the Teams that actually do the work **Can contribute** or **Can manage.**
This keeps everyone aware of how the work fits together — people can see the value stream and learn from it — while write access stays with the right Teams. It's also good practice: shared visibility helps Teams cross-pollinate and understand how their work ladders up.
When part of a value stream is genuinely sensitive and broad *visibility* isn't acceptable, split it. Create **two parallel L1 nodes** that mirror the same value stream — one open, one restricted — and place processes in whichever one matches their sensitivity.
You don't need to worry about there being "two nodes for one value stream." Klarity's Advisor reads the value stream names and the structure beneath them, and stitches the picture back together across parallel nodes on its own. As long as you **mirror the structure and naming** across the two nodes, Advisor quality and report quality are unaffected.
**Worked example 1 — "Financial Close" (lifting out an L2 process)**
**Before.** A single L1 value stream, `Financial Close`, holds everything from routine reconciliations to highly confidential executive-compensation accruals. With workspace roles alone, every Contributor and Admin can see all of it — including the comp work. That's the risk FGA exists to remove.
```text theme={null}
Financial Close (L1)
├── Month-End Reconciliation
├── Accounts Payable Close
├── Revenue Recognition
└── Executive Compensation Accruals ← sensitive; shouldn't be broadly visible
```
**After.** Split into two mirrored L1 value streams:
```text theme={null}
Financial Close (L1) General access: Open · Everyone → Can view
├── Month-End Reconciliation Finance → Can manage
├── Accounts Payable Close
└── Revenue Recognition
Financial Close — Compensation (L1) General access: Restricted
└── Executive Compensation Accruals Comp Committee → Can manage
Finance Leadership → Can view
```
Now the routine close work stays visible and well-understood across the org, while the compensation processes are invisible to everyone outside the `Comp Committee` and `Finance Leadership` Teams. Advisor still reasons across both nodes as one coherent "Financial Close" story for the people who can see both.
**Naming tip.** Give the parallel node a name that signals its purpose (`Financial Close — Compensation`) rather than a cryptic label. It reads clearly in the index and helps Advisor draw the connection.
Because access is always granted to Teams, how you shape your Teams matters as much as how you shape your process index.
* **Think of Teams as business units, not casual groups of people.** The clearest, most durable setups map each Team to a unit that genuinely owns a body of work — `Revenue Operations`, `Payroll`, `Deal Desk` — rather than to ad-hoc or one-off groupings.
* **Teams are flat in this version.** There's no nesting. To get the reach a hierarchy would give you, put a user on more than one Team — their access resolves to the most permissive of everything they're granted (see [Highest access wins](#highest-access-wins)).
* **Team attributes — geo, segment, route-to-market — aren't a separate dimension yet.** If you genuinely need to separate access along an attribute, model it as its own Team: `Deal Desk – EMEA`, `Deal Desk – NA`, `Enterprise – West`. Do this **only where the attribute actually drives who should have access**, and use it sparingly — spinning up a Team for every attribute combination quickly leads to Team sprawl that's hard to maintain.
**Rule of thumb.** Reach for an attribute-based Team when you can point to a real access boundary it enforces ("EMEA deal terms shouldn't be visible to NA"). If it's only an organizational label with no access consequence, keep it out of Teams.
**Worked example 2 — "Customer Lifecycle" (lifting out a deeper L3 process, with geo Teams)**
This one combines Pattern 2 (split the value stream) with Pattern 3 (attribute Teams) — and the sensitive process sits deeper, at L3.
**Before.** A single L1 value stream, `Customer Lifecycle`, contains a commercially sensitive process — `At-Risk Account Save Plays` (which accounts are flagged as churn risks, and the retention discounts and executive escalations offered to keep them), three levels down under `Renewals & Retention`. Everything else in the stream is routine and useful for the whole org to see. And because accounts are owned regionally, EMEA save plays shouldn't be visible to the NA team, and vice versa.
```text theme={null}
Customer Lifecycle (L1)
├── Onboarding (L2)
├── Adoption & Enablement (L2)
└── Renewals & Retention (L2)
├── Renewal Processing (L3)
└── At-Risk Account Save Plays (L3) ← commercially sensitive, region-owned; buried at L3
```
**After.** Lift the sensitive L3 subtree into a parallel restricted L1 node, **mirroring the path** (`Renewals & Retention → At-Risk Account Save Plays`) so Advisor still reads it as part of Customer Lifecycle. Then grant access using region Teams modeled as business units:
```text theme={null}
Customer Lifecycle (L1) General access: Open · Everyone → Can view
├── Onboarding
├── Adoption & Enablement
└── Renewals & Retention
└── Renewal Processing Customer Success → Can manage
Customer Lifecycle — Retention (L1) General access: Restricted
└── Renewals & Retention Customer Success – NA → Can manage
└── At-Risk Account Save Plays Customer Success – EMEA → Can manage
Revenue Leadership → Can view
```
What this achieves:
* The deep, sensitive L3 process is now isolated in its own restricted L1 node — invisible to everyone outside the region Customer Success Teams and Revenue Leadership — even though it originally lived three levels down.
* The **geo split** is handled with two flat Teams (`Customer Success – NA`, `Customer Success – EMEA`) standing in for a region attribute Klarity doesn't model natively, so each region only sees its own at-risk accounts. A leader who oversees both regions simply sits on both Teams.
* The routine Customer Lifecycle work stays open for the whole org, and Advisor reconciles both nodes into one coherent story for anyone who can see them both.
Same principle as example 1, one level deeper: no matter how far down a sensitive process sits, you protect it by mirroring its path into a parallel restricted L1 node. Keep the mirrored structure and naming aligned and Advisor stitches it back together.
## Good to know
* **Workspace Admins get no exception.** Being a Workspace Admin doesn't grant standing access to every value stream — admins can only manage value streams where one of their Teams has **Can manage**. If you want certain admins to manage any and all value streams, the recommended approach is to create an **Admin team** and add it, with **Can manage**, to the value streams they should administer. Multiple Teams can hold Can manage on the same value stream, so this layers cleanly on top of the owning Teams.
* **Restricted means invisible, not just locked.** A restricted value stream doesn't appear grayed-out for people without access — it's absent from their process index entirely, including everything nested inside it. It also won't surface in their search or Advisor.
* **Only Library-*linked* artifacts are protected.** Files uploaded straight to the Library, with no process link, are not governed by FGA. Link sensitive files to a process to bring them under access control.
* **Moving a process between value streams changes its access.** A process inherits the access of the L1 it lives under. Move it to a different value stream and it takes on that stream's audience — Klarity will confirm the change before applying it.
* **Contributions to processes you can't see show as *Restricted*.** In the Process Index **Sessions** (contributors) tab, you see the details of a contribution only for processes you have access to. Work other users did on processes you can't access appears labeled **Restricted** — you'll see that a contribution happened, but not its content.
* **The Operations tab is scoped by role and by process access.** With FGA enabled, Contributors and Viewers see only their own operations in the **Operations** tab; only Workspace Admins can see all operations. And regardless of role, if an operation ran on a process you don't have access to, the output artifacts tied to that process may not be visible to you.
## FAQ
No — access is always granted to Teams. For the large organizations Klarity serves, individual grants become very hard to audit and maintain over time ("why does *this specific person* have access, separately from their Team?"). Teams keep access legible and reviewable. If someone needs access, add them to the appropriate Team.
Teams are flat, and you get the same flexibility a hierarchy would give you by putting a user on multiple Teams — their access is always the most permissive of everything they're granted. So a person can belong to a broad Team *and* a specialized one and pick up access from both, without any nesting to manage.
Not in this version. Access is resolved at the value stream (L1) level and everything beneath inherits it. Klarity's agents work reliably against access boundaries at the value stream level today, and we're extending that same reliability to deeper levels as the models mature. In the meantime, the [structuring patterns](#structuring-your-process-index-for-access-control) cover the vast majority of needs: broaden read and tighten write, split the stream into parallel open/restricted nodes, and model Teams as business units.
We're actively building toward it. Rather than commit to a date, we're letting the capability follow the reliability of the underlying models — we won't ship access control at a level until the agents that read and write there respect it dependably. Anything you set up now carries forward with no re-work.
No. Workspace Admins are bound by Fine-Grained Access Control with no exceptions. To manage access to a value stream, you must be on a Team that has **Can manage** on it — being a Workspace Admin alone doesn't grant it. If you want certain admins to manage any and all value streams, create an **Admin team** and add it, with Can manage, to the value streams they should administer. Multiple Teams can hold Can manage on the same value stream, so this coexists with the value stream's owning Teams.
No — and no one is granted an exception. When a value stream (L1) is restricted, it's visible only to the Teams with access, admins included. A Workspace Admin can see the processes and their data only if they're on a Team that has access to that restricted value stream.
The higher one. Access always resolves to the most permissive grant a user qualifies for, across General access and all their Teams.
You might, if none of your Teams is on the restricted list. Klarity warns you before applying a change that would remove your own access, so you can add your Team first. (A managing Team or admin can always restore access later.)
No. Advisor reads value stream names and structure and reconciles parallel nodes on its own. Keep the naming and structure mirrored across the two nodes and quality is unaffected.
Yes — all of them. Interviewer, Companion, Advisor, global AI chat, file-upload operations, and the MCP tools all operate strictly within the access you have.
FGA can help here. Now that access can be set per value stream, you could bring that work into a single workspace and separate the audiences with access instead. Merging existing workspaces is on the roadmap — reach out if you have a need and we'll help you plan it.