1. Docs
  2. Scope Model

Identities, Memberships & Assignments

How a person exists at three layers (an Account identity, access to an Environment, and a role assignment), and what "invited", "a member" and "assigned" each mean.

Overview

A person in Canopy exists at three independent layers, and a record at one layer doesn't imply the others. Understanding the split explains why the Console's setup guide and Environment cards say what they say: why someone you invited can show as pending, or why an Environment with members can still read as Awaiting users.

The three layers

Identity → Environment access → Role assignment

Each layer answers a different question about a person:

Identity: the person exists in the Account: a real human with an email and credentials. Created when an invite is accepted or by a direct create, not when an invite is sent.Environment access: the identity is a member of a specific Environment and can sign into it. An identity can exist in the Account with no membership anywhere, and membership in one Environment never implies another.Role assignment: the identity holds a role at a node in an Environment it belongs to, so it can be authorized there. A member with no assignment can sign in but is allowed nothing.

Because the layers are independent, "this person exists" and "this person can do something in this Environment" are different statements. The Developer Console reflects operational reality, not just whether a row exists somewhere.

Inviting vs. accepting

Sending an invite is not the same as accepting one

This is the most common point of confusion. The two actions create different things:

Sending an invite creates an invitation and emails it. It does not create the identity, the membership, or any assignment.Accepting the invite, where the recipient clicks the link and sets a password, creates the identity (if it's new), its membership in the Environment, and, when the invite carries a role, the initial role assignment.With organizations on, an invitation whose node is an organization, or a place beneath one, also makes the person a member of that organization when accepted: a separate record from Environment access, which every role beneath the organization stands on and switched off when they are removed from it. See Enable Organizations and Manage Members.Until the recipient accepts, the setup guide's Invite Identities step shows pending ("your part is done, waiting on them"), not complete. There's no need to re-send.

What the setup states mean

The setup guide and the Environment cards read from the same data, for the Environment in question.

An Environment card shows one of three states:

Not set up: the Environment is missing at least one of custom permissions, custom roles, or a permission mapped to a role. The configuration layer is incomplete.Awaiting users: the configuration is done, but no identity has a role assignment in this Environment yet. Configured, but unused.Active: configured and at least one identity has a role assignment here. Operational.

Both invite and assign setup steps are scoped to one Environment. Invite Identities is complete once at least one identity is a member there, with or without a role, and pending while an invite is outstanding. Assign Role to Identity is complete once an active assignment exists there, and pending while an invite that carries a role is outstanding. That's why inviting and assigning in Development doesn't complete the steps for Production.

Next step

Once an identity is a member of an Environment, give it access by assigning a role at a hierarchy node there.

Environment
API version
v1.0
On this page Was this page helpful?

Tell us how we can improve this guide.