1. Docs
  2. Console and Workspace

Console and Workspace

Canopy has two places you sign in to. Which one you land in depends on what you administer.

Overview

Canopy separates the people who build an integration from the people who run an Account, and gives each their own application. They are not two logins: you sign in once, and a product switcher moves you between whichever you can reach.

Signing in does not always take you to the same place. Canopy looks at what you administer and opens the application that matches, or asks which one you want if you also administer people in the Workspace.

The two applications

Each is deployed separately. The Console lives on a console. subdomain and the Workspace on a workspace. one, and both are signed in to with the same credentials:

Developer Console

Where an integration is built. Applications and environments, the hierarchy, organizations, roles and permissions, sign-in settings and branding, API keys, OAuth clients, webhooks, SSO and directory sync, and the audit log.

Admin Workspace

Where an Account is run. The people in it, invitations, who administers what, recent activity, billing, and the Account's own settings.

Where things live

Most things belong to exactly one application, and the name usually gives it away. The exception that matters most is identities:

Identities are the same people in both

There is one set of end users. Both applications show them, and what differs is the job you are there to do rather than the records you are looking at:

In the Console, identities are test data for the integration. You create or invite them in a non-production Environment and give them roles, then sign one in through your app and evaluate a permission at a node through the API to prove the integration behaves. That is development work, and it belongs in a non-production Environment.In a production Environment, the Console's identity pages stay where they are but stop listing people, and explain the restriction instead. Those are real people, and administering them is the Workspace's job. The exception is production access: the account owner always holds it, and an account administrator can grant it in the Workspace to a developer who genuinely needs it, usually to reproduce a customer's report against the data it concerns.In the Workspace, the same identities are the people you administer, listed with the actions your authority allows.

If a page in these docs tells you to open Identities, the surrounding section says which application it means.

See every page of both applications, and what opens each →

Which one is yours

These docs are written for both audiences, in different language, because the two jobs are different.

Building an integration? Getting Started, Core Concepts, Developers and the API Reference are yours. You will work in the Console and call the API.Administering people? You will work in the Workspace, and the Administration section of these docs is written for you. Start with Your Responsibility, because what you hold decides what the rest of the application shows you.

Do not be surprised if either application shows you less than these docs describe. Both render from what you have been granted: an action you cannot take is absent rather than disabled, a settings form you can read but not change shows its values read-only, and a page you cannot open is not offered.

Next Step

Building the integration? The Quick Start has a short guide for each building block: permissions, roles, identities, assigning roles, the hierarchy, and single sign-on.

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

Tell us how we can improve this guide.

Canopy