> ## 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.
# Bindings
> Grant access by linking a user group to a role and a scope.
A **binding** is the access grant. It connects three things: **who** (user group), **what** (role), and **where** (scope).
## The binding formula
**Who** gets access
**What** they can do
**Where** it applies
```
Binding = User Group + Role + Scope
```
Think of it as: "The **Operations Team** can perform **Operator actions** on **Carrier TRLDBLKDRY**"
## View existing bindings
Use the list to search by group, role, or resource. This is helpful for audits or troubleshooting access issues.
## Create a new binding
From the Bindings page or Dashboard, click **Add Binding**.
Choose which group should receive access. If you haven't created the group yet, do that first.
Choose what the group can do. Pick a built-in role or a custom role you've created.
Choose where the access applies:
* **Carrier** — access to the entire carrier
* **Customer** — access limited to a specific customer
* **Organization** — access across multiple carriers
Carrier-level scope grants broader access. Only use it when the group truly needs access to everything.
Review your selections and save. The binding takes effect immediately.
### Dialog fields explained
| Field | Description |
| --------------------------- | ---------------------------------------- |
| **Group** | The user group that will receive access |
| **Role** | The set of permissions to grant |
| **Primary Resource Type** | Usually "Carrier" — the main scope level |
| **Primary Resource** | The specific carrier (e.g., TRLDBLKDRY) |
| **Secondary Resource Type** | Optional narrower scope (e.g., Customer) |
## Binding details
## Common mistakes
Picking **Carrier** scope when you meant **Customer** scope grants much broader access than intended. Always double-check the scope before saving.
| Scope | Access level |
| ------------ | -------------------------------- |
| Customer | Limited to one customer's data |
| Carrier | All data for the carrier |
| Organization | All carriers in the organization |
Linking a group to the wrong role (e.g., Admin instead of Operator) can grant too much access. Review role permissions before creating bindings.
Creating multiple bindings with the same group/role but different scopes is sometimes intentional, but can also be confusing. Document why you need multiple bindings.
Changes to bindings take effect immediately. There's no undo button, so review carefully before saving.
## Best practices
Grant the minimum access needed. It's easier to add permissions later than to clean up over-provisioned access.
Never create bindings directly to users. Always use groups, even for single users.
When creating bindings, make sure the group name and role name clearly indicate the purpose.
## Related: Admin Portal
Create groups before binding
Understand what roles include
Review binding changes
Quick term reference
## Related: IAM Concepts
Deep dive into identities, resources, and permissions
How bindings create policies
Understanding scope inheritance
Granting customer access with bindings