Skip to main content

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.

A feature set is one of the columns you see when you open the IAM matrix on the 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 hand-picked from the raw permission list:
ApproachWhat you maintainRisk over time
Custom role from individual permissionsEvery individual permission, foreverHigh — 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 columnsJust the list of features you want enabledLow — 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 suffixWho it’s forWhat it lets them do
— ViewAnyone who should see the featureRead everything in the feature, run searches, use typeaheads and filters. Can’t make changes.
— OperateDay-to-day users who own their own workCreate, 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.
— ManageAdmins, moderators, and feature ownersAct 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 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, don’t open the raw permission picker unless you need a permission no feature set covers. Instead:

Create the role

From the Roles page, click New role and give it a clear name and description.

Pick the feature columns

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 and bind

Save the role, then create a binding 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.

Roles

The page where the IAM matrix lives — manage built-in and custom roles

Bindings

Connect roles to user groups at the right scope

Policies & Roles

How roles fit into the broader IAM model

Notes permissions

A complete worked example, including per-role defaults