Skip to main content
A binding is the access grant. It connects three things: who (user group), what (role), and where (scope).

​
The binding formula

User Group

Who gets access

Role

What they can do

Scope

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.
Bindings list showing groups, roles, and resources

​
Create a new binding

Click Add Binding

From the Bindings page or Dashboard, click Add Binding.

Select the user group

Choose which group should receive access. If you haven’t created the group yet, do that first.

Select the role

Choose what the group can do. Pick a built-in role or a custom role you’ve created.

Select the scope

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.

Save

Review your selections and save. The binding takes effect immediately.
Create New Binding dialog with group, role, and resource fields

​
Dialog fields explained

FieldDescription
GroupThe user group that will receive access
RoleThe set of permissions to grant
Primary Resource TypeUsually “Carrier” — the main scope level
Primary ResourceThe specific carrier (e.g., TRLDBLKDRY)
Secondary Resource TypeOptional narrower scope (e.g., Customer)

​
Binding details

Binding details panel

​
Common mistakes

Wrong scope

Picking Carrier scope when you meant Customer scope grants much broader access than intended. Always double-check the scope before saving.
ScopeAccess level
CustomerLimited to one customer’s data
CarrierAll data for the carrier
OrganizationAll 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.

User Groups

Create groups before binding

Roles

Understand what roles include

Activity Log

Review binding changes

Glossary

Quick term reference

IAM Concepts

Deep dive into identities, resources, and permissions

Policies & Roles

How bindings create policies

Resource Hierarchy

Understanding scope inheritance

Customer Portal

Granting customer access with bindings