1. Docs
  2. Assign Permissions

Assign Permissions

Connect roles to identities at a hierarchy node — with optional time bounds and automatic cascade.

Overview

An assignment is the link between a role and an identity. It's where access actually gets granted — until a role is assigned to someone, nothing it bundles applies to anyone. Each assignment also points at a node in your hierarchy — that's the scope where the role's permissions take effect — and can carry optional effective_from / effective_to dates for time-bound access. Assignment is one of three layers in the identity model — the identity must exist at the Account first, and an AppMembership ties it to a specific Application. See the Identities overview for the full picture.

Scope

Assignments are scoped to an Environment

When you assign a role to an identity, the assignment lives in the active Environment — the one selected on the Tenant › Applications page. Identities themselves are shared across every Environment in your Account, but a role assignment is not — each Environment maintains its own record of who holds what.

An identity assigned Regional Manager at a node in Development is not assigned that role in ProductionEach new Environment starts with zero assignments — even after a Promote, the target env's permissions, roles, and hierarchy are copied but assignments are deliberately left empty for you to configureTime bounds (effective_from / effective_to) apply per-env — an assignment can be active in one env and expired in another

This is what makes safe iteration possible: you can hand out roles freely in Development to test invite flows or evaluator behavior, with zero risk of accidentally granting access in Production.

View the Environments reference →

Hierarchy Cascade

Assignments aren't just role + identity — they're scoped to a node in your Environment's hierarchy. An assignment at a parent node cascades down: every descendant inherits it automatically. This is the core of Canopy's hierarchical RBAC. In flat RBAC mode, all assignments live at the root node, so the cascade reaches the entire Environment by default.

Lifecycle

Every assignment carries an effective window. effective_from defaults to the moment the assignment is created; effective_to defaults to never. Together they place the assignment in one of three states:

Scheduled: effective_from is in the future. The assignment exists but doesn't grant access yet.Active: the current time falls between effective_from and effective_to. Access is granted.Expired: effective_to has passed. The assignment no longer grants access but stays in your audit trail.

The evaluator factors the lifecycle in automatically — a scheduled assignment doesn't grant access until its start date, and an expired one stops granting on its end date. No cron jobs, no manual cleanup.

Direct vs Inherited

When evaluating a permission for an identity at a node, Canopy walks the hierarchy from that node up to the root, gathering every assignment that applies. The result is a union of:

Direct assignments: made at the node itself.Inherited assignments: made at any ancestor node (root, region, department, etc.).

An identity needs only one assignment at the highest applicable level — no per-leaf duplication. Assign a Regional Manager role at the North America node and it covers every office, team, and identity beneath it.

Next Step

Assignments connect roles to identities — and identities themselves have their own lifecycle, types, and management surface worth understanding.