Control who can see and work on each value stream in your process index using Teams.
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.
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 — 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.
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.
Hide the process index entirely
Want to hide the process index from someone entirely? → Basic Contributor role. Basic Contributors have no process index access at all, with or without FGA. This is a Workspace-level role, not FGA.
Set different levels of access
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.
Route who contributes where
Want to route different Teams to contribute to different parts of the process index? → Context Store and FGA.
The Context Store 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).
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.
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.
A Team is a named group of users in your workspace. Teams are the unit you grant access to.
A workspace holds many Teams; a Team holds many people. Access is always granted to a Team — never to one person directly — and someone can sit on more than one Team.
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).
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.
Select Create team and name it after how people actually work (Revenue Operations, Payroll, Security).
3
Add members
Search for people by name or email and add them. A user can be on as many Teams as needed.
4
Assign Team owners (optional)
Optionally assign one or more Team owners to keep membership current.
5
Give the Team an icon
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.
Step 1 — name the Team and choose an icon.
Step 2 — add members and set Team owners.
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.
FGA doesn’t replace workspace roles — it works with them. Your role sets the ceiling; FGA decides which value streams you reach within it.
Two things decide what someone can do on a value stream: their workspace role (the ceiling) and the access their Teams are granted. They get whichever is lower.
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.
Every combination of workspace role and value stream access, worked out — and what the person ends up able to do.
Teams and levels are the setup; this is how permissions actually resolve once they’re in place. Expand any topic:
Checking access
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.
What each level can and can't do, action by action.
Permission levels — Can manage, contribute, view
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.
The levels build on each other: Can contribute does everything Can view does plus edit, and Can manage does everything Can contribute does plus move, delete, and change who has access. Pick the smallest that fits.
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.
The two general-access modes — Open vs Restricted
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.
Open value streams include the built-in Everyone Team, giving the whole workspace a baseline level. Restricted ones drop Everyone — only the Teams you list can see them.
Highest access wins — how multiple grants resolve
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.
Someone on more than one Team keeps the most generous grant. Access only ever adds up — a narrower grant never pulls it down.
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.
What's covered by access
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.
Access covers every process in the value stream and the artifacts linked to them. The one exception: files uploaded straight to the Library with no process link — link them to a process to bring them under access control.
Access applies everywhere — including AI
FGA isn’t just a UI filter. Every way Klarity touches the process index respects it:
The Interviewer and Companion can only capture into processes you can contribute to.
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.
You set access once, on the value stream (L1) node. Every process beneath it inherits that access, and several Teams can be on the same value stream — each at its own level.
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.
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.
Pattern 1 — Broaden read, tighten write
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.
Pattern 2 — Split a value stream into parallel L1 nodes
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.
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:
Financial Close (L1) General access: Open · Everyone → Can view├── Month-End Reconciliation Finance → Can manage├── Accounts Payable Close└── Revenue RecognitionFinancial 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.
Pattern 3 — Model Teams as business units, and use attribute Teams sparingly
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).
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.
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:
Customer Lifecycle (L1) General access: Open · Everyone → Can view├── Onboarding├── Adoption & Enablement└── Renewals & Retention └── Renewal Processing Customer Success → Can manageCustomer 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.
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.
Can I grant access to an individual person instead of a Team?
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.
Can Teams be nested or hierarchical?
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.
Can I set different access on a sub-process, lane, or folder within a value stream?
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 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.
Is there a timeline for deeper-level access control?
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.
Can a Workspace Admin manage access to a value stream when none of their Teams has Can manage on it?
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.
Can a Workspace Admin see a restricted value stream their Teams aren't on?
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.
A user is on two Teams with different levels — which applies?
The higher one. Access always resolves to the most permissive grant a user qualifies for, across General access and all their Teams.
If I switch a value stream from Open to Restricted, will I lose my own access?
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.)
Does splitting a value stream into two nodes hurt Advisor or report quality?
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.
Do the AI agents respect these permissions?
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.
We run several workspaces to keep audiences separate. Should we consolidate?
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.
