1. Docs
  2. Introduction

Introduction

What Canopy is, why flat RBAC breaks as your customers grow, and how hierarchical authorization replaces it.

Overview

Canopy is hierarchical identity and access management for B2B SaaS. It lets you model real organizational structures, regions, departments, and teams, and assign roles at any level, with permissions that inherit automatically through the hierarchy. Instead of building custom authorization logic, your application asks Canopy one question:

Can this user do this action in this part of the organization?

Canopy answers it. Everything else in these docs is about how you configure that answer.

That configuration lives inside three layers. An Account is your company, and owns billing and the admins who sign in. Inside it you create one or more Applications, one per product whose access you manage. Inside each Application you create Environments, isolated copies of your permissions, roles, and hierarchy, typically development and production. Role assignments and the hierarchy itself live in an Environment, so a change you make in development never reaches production.

 Read about account structure →

You configure all of it from the Developer Console. There is a second application, the Admin Workspace, where the people in an organization are administered. Which one you land in when you sign in depends on what you administer.

 Read about Console and Workspace →

The problem

A B2B product usually ships with three flat roles, Admin, Manager, and Viewer. That holds up until a customer has internal structure of their own.

What your customers start asking for
Regional managers with access across every location in their regionDepartment heads with authority scoped to their own departmentAccess that keeps working as the organization reorganizes and grows
Where flat RBAC breaks
Access has to be assigned again at every single locationNothing inherits, so a newly added office starts with no access at allEvery change to the customer's structure becomes engineering work on your side

So teams build a custom authorization system instead, and each one rebuilds the same thing from scratch.

How Canopy solves it

Assign once, inherit everywhere

Canopy replaces flat RBAC with hierarchical RBAC. A role is assigned at a node in the organization tree, and the permissions it carries cascade to every node beneath it.

Assign a role once, at a parent nodeIts permissions apply automatically at every descendant nodeThe customer's org structure becomes the access model

Add a new office under a region and nothing needs updating. The roles already assigned at the region cover it.

That removes most of what teams otherwise write by hand: no hardcoded access rules, no role assignments duplicated across locations, no custom org model to maintain, and no permission logic to debug by reading code.

Why this is different

Most platforms stop at authentication or flat roles. Canopy combines three things:

Hierarchical RBAC

Permissions inherit through an organization tree of any depth.

Visual control plane

Non-engineers manage hierarchy and access without touching code.

Flat to hierarchical

Start at a single root node and add structure later, with no migration.

Who uses Canopy

Three groups of people depend on Canopy, and only two of them ever see it:

Developers integrate the API, define the permission catalog, and stop building authorization systems from scratch.Operators manage the hierarchy, assign access, and answer permission questions without engineering help.End users, called identities in Canopy, simply use your product. They never see Canopy, but everything they are allowed to do is decided by it.

Platform and product

Canopy deliberately keeps two populations of people apart. They authenticate separately and never appear in the same directory:

Platform (admins)
Sign in to the Developer ConsoleConfigure hierarchy, roles, and permissions within an EnvironmentCan belong to more than one Account
Product (identities)
The end users of your applicationBelong to a single Account, and are granted access per EnvironmentReceive their permissions through role assignments on the hierarchy

Admins configure access. Identities are subject to it.

Keeping the two separate is what lets an Account's admins reconfigure authorization without ever appearing as users of the product they administer.

How it works

What you set up
Define your permission catalogCreate the roles that bundle those permissionsBuild the organization hierarchyAssign roles to identities at specific nodesEvaluate permissions at runtime from your application
What Canopy does on every check
Walks the lineage of the node in questionResolves every role assignment along that lineageApplies inheritance down the treeReturns a structured decision your application can act on

The hierarchy page covers node types, depth limits, and exactly how the cascade is resolved.

Read about hierarchy →

Next Step

The Quick Start walks through a permission catalog, roles, a hierarchy, and a first permission check, end to end.

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

Tell us how we can improve this guide.

Canopy