> ## 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.
# Glossary
> Key terms used in the Admin Portal.
This glossary defines the key terms you'll encounter when using the Admin Portal. Understanding these concepts will help you manage access effectively.
For a deeper technical understanding, see the [IAM Concepts guide](/user-docs/iam/concepts).
## Core concepts
The rail operator or business you are managing. Everything in the portal is scoped to a carrier.
**Example:** TRLDBLKDRY, BNSF, UP
Your carrier appears at the top of the left sidebar. All users, groups, roles, and bindings you see are specific to that carrier.
A higher-level grouping that can include multiple carriers.
**Use case:** A company that operates several regional railroads might group them under one organization for easier management.
Organizations allow shared settings and cross-carrier access when needed.
An individual person who can sign in to Cedar.
Each user has:
* Email address (used for login)
* Display name
* Account status (Registered, Pending, etc.)
* MFA settings
Users don't have direct permissions—they get access through group membership.
A named team of users managed together.
**Purpose:** Groups make access management scalable. Instead of assigning permissions to each user individually, you assign them to groups.
**Best practice:** Always use groups, even for single users. It's easier to add more people later.
A named set of abilities (permissions).
**Types:**
* **Built-in roles** — provided by Cedar for common jobs
* **[Feature sets](/user-docs/iam/feature-sets)** — the columns of the IAM matrix; check one to grant a whole product feature
* **Custom roles** — tailored to your organization's needs (best built from matrix columns)
Roles define *what* someone can do, not *where* they can do it. The *where* comes from the binding's scope.
One column of 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**, **Inventory waybills — Operate**, or **Reporting — Manage**. Checking the box on a row grants every permission that role needs to use that feature.
**Three standard levels:**
* **View** — read-only access to the feature
* **Operate** — create, edit, and delete your own work in the feature
* **Manage** — moderate other people's work and change feature-level settings
**Why use them:** Cedar maintains the columns. When a feature gains a new capability, every role with that column checked picks it up automatically — no admin work required. Custom roles built from hand-picked permissions don't get this, and silently drift as the product grows. See the [Feature Sets guide](/user-docs/iam/feature-sets) for full details.
The access grant that connects a user group to a role and a scope.
**Formula:** `Binding = User Group + Role + Scope`
**Example:** "The Operations Team (group) can perform Operator actions (role) on Carrier TRLDBLKDRY (scope)"
Without a binding, groups have no permissions.
Where a role applies, such as a carrier or customer.
**Scope levels (from narrow to broad):**
| Scope | Access |
| ------------ | -------------------------------- |
| Customer | One customer's data |
| Carrier | All data for the carrier |
| Organization | All carriers in the organization |
Always use the narrowest scope that meets your needs.
## Portal sections
Overview of access metrics and recent activity
Where you create and manage access grants
Where you view and create permission sets
Where you manage individual accounts
Where you organize users into teams
Audit trail of all changes
Identity provider provisioning connections
Organization setup, enablements, API keys
## How concepts relate
```mermaid theme={null}
flowchart LR
U[Users] --> G[User Groups]
G --> B[Bindings]
R[Roles] --> B
S[Scope] --> B
B --> A[Access Granted]
style U fill:#E0F2FE
style G fill:#E0F2FE
style R fill:#F5F3FF
style S fill:#ECFDF5
style B fill:#FEF3C7
style A fill:#D1FAE5
```
1. **Users** are added to **User Groups**
2. **Roles** define permissions
3. **Bindings** connect groups to roles with a scope
4. Result: **Access is granted**
| Term | Answers | Managed in |
| ------- | ---------------------- | ---------------- |
| User | Who is this person? | Users page |
| Group | What team are they on? | User Groups page |
| Role | What can they do? | Roles page |
| Scope | Where can they do it? | Bindings page |
| Binding | Put it all together | Bindings page |
## Deep dive: IAM Concepts
These conceptual guides explain the **why** behind IAM and provide technical details for advanced users.
How identity & access management works in Cedar
Deep dive into identities, resources, and permissions
How bindings create policies
The columns of the IAM matrix — Cedar curates them so your roles stay current
The problem IAM solves
## Start using the Admin Portal
Practical walkthrough
Admin Portal introduction