Account Structure

When you sign up for Canopy, you create an Account, the top-level container that owns billing, admin users, and everything inside it. Inside an Account you create Applications, one for each product whose access you want to manage. Inside each Application you create Environments: independent copies of your permissions, roles, and hierarchy (typically one per stage: development, production, etc.). The three layers (Account → Application → Environment) are the structural backbone of every other concept in Canopy.

An Account is your company's container in Canopy. It owns billing, the administrators who sign in to Canopy, and the directory of identities (your end users) that every Application in the Account can draw from. An identity can exist purely at this Account layer with no access to any Environment yet, which is useful for pre-provisioning, federated/SSO directories, or staged onboarding. Access is granted one Environment at a time: you add the person to a specific Environment, then assign them a role there to give them real permissions. Which Applications someone can reach simply follows from the Environments they've been added to. So there are three independent steps: listed in the directory, added to an Environment, and assigned a role. See the Identities overview for the full picture. When you sign up, you create exactly one Account, and everything else you build in Canopy lives somewhere inside it.

Admin users aren't locked to a single Account. The same sign-in can be a member of several: a second Account you created for a sandbox, or another company's Account you were invited into. You end up in more than one either by accepting an admin invitation into another Account, or by registering a new Account with an email that already owns one. That second path looks like any other signup on screen (a generic "check your email" page, so the form never reveals whether an email is registered), continues from the emailed notice, and after you sign in the new Account's name is shown for your explicit confirmation before anything is created. Each Account remains a fully separate tenant with its own billing, Applications, admin users, and identity directory; membership just means one set of credentials can reach more than one of them.

An Application is a single product whose access you want to manage. If you have one product, you have one Application; if you run multiple products under the same company (say a customer-facing app and an internal admin tool), each one is its own Application. Two Applications under the same Account are completely independent: they don't share permissions, roles, hierarchy nodes, OAuth clients, or API keys.

An Environment is where all of Canopy's access-control configuration actually lives. Two Environments inside the same Application are fully isolated: they share no access-control state. Each Environment picks its own access model (flat or hierarchical), optionally switches on the organizations container beside it, defines its own structure, and owns its own permissions, roles, role assignments, API keys, OAuth clients, and webhooks. One env can run in flat mode while a sibling runs in hierarchy mode; they don't constrain each other.