> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cedarai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Feature Sets
> Curated columns in the Admin Portal IAM matrix that grant a whole product feature in one click — and stay current as Cedar evolves.
A **feature set** is one of the columns you see when you open the IAM matrix on the [Roles](/user-docs/admin/roles) page. Each column represents a single product feature at a specific access level — for example **Notes — View** or **Inventory waybills — Operate**. Checking the box on a row grants every permission that role needs to use that feature.
## Why feature sets exist (the maintainability story)
The biggest reason to use feature sets — and the one most teams underestimate — is that **Cedar curates them, so you don't have to**.
When a feature gains a new capability — a new filter, a new bulk action, a new export option, an extra typeahead lookup — Cedar updates the feature set behind the scenes. Every role that has that column checked picks up the new capability automatically on the next deploy. Your admins do nothing.
Compare that to the alternative — a [custom role](/user-docs/admin/roles#create-a-custom-role) hand-picked from the raw permission list:
| Approach | What you maintain | Risk over time |
| ------------------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Custom role from individual permissions** | Every individual permission, forever | High — when Cedar adds a permission to support a feature upgrade, your role silently misses it until someone notices something is broken. |
| **Custom role composed from feature set columns** | Just the list of features you want enabled | Low — Cedar keeps each column current. Your role inherits the upgrades automatically. |
If you remember nothing else from this page: **prefer feature-set columns over hand-picked permissions whenever the option exists**. It's the single biggest lever you have to keep IAM low-maintenance as the product grows.
## What you see in the Admin Portal
The IAM matrix on the Roles page is a grid:
* **Rows** are the roles available in your carrier (built-in roles like `arms.carrierAdmin`, plus any custom roles you've created).
* **Columns** are feature sets. Headers read like **Notes — View**, **Notes — Operate**, **Notes — Manage**, **Inventory waybills — View**, **Reporting — Manage**, and so on.
* **Cells** are checkboxes. A check means "this role can do this feature, at this level."
Granting a whole feature is one click. Revoking it is one click. There's nothing else to configure — no individual-permission picker, no manual list of capabilities to keep in sync.
## The three access levels
Most features ship three columns. A role can carry any subset of them; what you check depends on what that role's users should be able to do.
| Column suffix | Who it's for | What it lets them do |
| ------------- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **— View** | Anyone who should see the feature | Read everything in the feature, run searches, use typeaheads and filters. Can't make changes. |
| **— Operate** | Day-to-day users who own their own work | Create, edit, and delete *their own* work in the feature. Implies everything in **View** — you don't need to check both unless you want to be explicit. |
| **— Manage** | Admins, moderators, and feature owners | Act on *other people's* work in the feature (edit or delete any author's record), and change feature-level settings. Layer this on only when that role should have moderation or configuration authority. |
Not every feature uses every level. A read-only data surface like AEI may only ship a **View** column. A configuration-only feature like automation rules may ship only **Manage**. The matrix shows you exactly what's available for each feature in your carrier.
## A worked example: Notes
Notes ships three columns:
* **Notes — View** · Read note threads, run the in-drawer search, and use the `@` typeahead anywhere references render.
* **Notes — Operate** · Write your own notes; edit and delete what you wrote.
* **Notes — Manage** · Moderate the whole carrier — edit or delete any user's note regardless of who wrote it.
Cedar pre-checks these for every built-in role with sensible defaults: `arms.carrierAdmin` gets all three; `arms.carrierOperator` gets View and Operate; `arms.customerOperator` gets just View. See [Notes permissions](/user-docs/arms/ops/notes#permissions) for the complete per-role default table.
When Notes ships a new capability later — say, a "pin a note to the top of the thread" action — Cedar adds the underlying permission to **Notes — Operate**. Every role with that column already checked picks up "pin" the next time the admin service redeploys. You don't change anything in the matrix.
## Defaults Cedar ships
You usually don't need to touch the matrix at all. Cedar pre-checks the right columns on every built-in role so a fresh carrier has the intended feature coverage out of the box.
You only need to open the matrix when you want to:
* **Customize coverage** — for example, grant **Notes — Manage** to a non-admin moderator role, or remove **Notes — View** from a role you'd rather not have reading notes.
* **Compose a custom role** — pick the feature sets you want this role to inherit instead of hand-picking individual permissions.
* **Audit** — see at a glance who has access to what feature.
## Building a custom role with feature sets
When you create a [custom role](/user-docs/admin/roles#create-a-custom-role), don't open the raw permission picker unless you need a permission no feature set covers. Instead:
From the Roles page, click **New role** and give it a clear name and description.
Find your role's row in the matrix and check every feature column the role should be able to use. Use the column search to jump to a specific feature.
Save the role, then create a [binding](/user-docs/admin/bindings) to grant it to a user group at the right scope.
Future you will thank present you when Cedar adds new capabilities to those features and your custom role keeps working without any matrix updates.
Removing a feature column from a built-in role takes effect carrier-wide on save. If you're trimming defaults, make sure the affected user groups still have the access they need (or get a heads-up first).
## A few practical notes
* **Column names follow `Feature — Level`** so they sort and group naturally in the matrix. All `Notes —` columns sit together, all `Inventory waybills —` columns sit together, and so on.
* **Some role names in your Roles list start with `fs.`** (for example `fs.linda.notes.view`). Those are the feature sets themselves, surfaced as roles for transparency. You don't normally interact with them directly — you interact with the matrix columns instead.
* **Bindings still attach to roles, not to feature sets directly.** The matrix is just a faster, lower-maintenance way to decide what each role can do.
## Related
The page where the IAM matrix lives — manage built-in and custom roles
Connect roles to user groups at the right scope
How roles fit into the broader IAM model
A complete worked example, including per-role defaults