Manage Applications and Environments

Create, rename, or delete an Application

In the Developer Console, Tenant → Applications lists every Application in the Account as a tile, each with its Environment cards beneath it. A new Application is seeded with a Development and a Production Environment.

Application: Developer Console
Path: TenantApplications
Opens with: applications.view Read the Account's Applications and Environments, and open an Environment's Overview.
Context: Account-wide. No Application or Environment selection applies.

Create, rename, or delete an Application

Open Applications from the left nav under Tenant and click Create Application in the page header. The Create Application dialog opens; enter a name and click Create Application. A new tile appears with Development and Production.

To rename, open the tile's gear menu (Application settings) and click Edit Application. Change the name and click Save Changes. Only the display name changes; the API identifier, Environments, roles, identities, and API keys are unaffected.

To delete, open the gear menu and click Delete Application. The Delete Application dialog keeps Delete disabled until you type the Application's exact name. Type it and click Delete; a Deleted … toast appears and the tile is removed. The only remaining Application cannot be deleted; its menu item is muted.

Create, rename, or delete an Environment

Each Environment card carries a ⋮ menu (Environment actions). Environments are where permissions, roles, assignments, keys, and integrations live, so each one is an independent copy of that configuration.

Create, rename, or delete an Environment

Click the Add Environment tile on the Application's row. The Create Environment dialog opens. Enter a name, leave Copy configuration from on Start with an empty environment, and click Create Environment. A new card appears.

To rename, open the card's ⋮ menu and click Edit Environment. Change the name and click Save Changes. The API identifier does not change.

To record that an Environment holds real end users, open its ⋮ menu and click Mark as production, then confirm. From then on the Console's identity pages there stop listing people, who are managed in the Admin Workspace instead (see Console and Workspace). This cannot be undone, so the item appears only on Environments not yet marked; the seeded Production Environment already is.

To delete, open the ⋮ menu and click Delete Environment. The Delete Environment dialog keeps Delete disabled until you type the Environment's exact name. Type it and click Delete; a Deleted … from … toast appears and the card is removed. The default Environment and the last remaining one cannot be deleted; the item is muted for them.

Choose the default Environment

Every Application has one default Environment, marked with a Default pill: the one an administrator lands on when they open the Application without picking an Environment.

Choose the default Environment

On the card of the Environment that should become the default, open the ⋮ menu and click Set as Default. On the current default the item is disabled.

The Set default environment dialog shows the current default and the new one; click Set as Default. The Default pill moves, and Delete Environment becomes muted on the new default and enabled on the old one.

Clone or move configuration between Environments

Configuration travels three ways: cloned into a new Environment as it is created, exported to a JSON file and imported elsewhere, or promoted directly. What travels is the permission catalog, the Environment's roles and their permissions (never an organization's own roles: an import leaves the target's in place), the access model with its hierarchy schema and nodes, whether organizations are switched on (never the organizations themselves), OAuth clients, and webhook subscriptions. API keys, identities, role assignments, and secrets never do; imported OAuth clients and webhooks get freshly minted secrets.

Clone or move configuration between Environments

Clone on create: in the Create Environment dialog, set Copy configuration from to an existing Environment. A line under it shows the access model the new Environment will start in, with a Flat or Hierarchy badge and an Organizations badge when the source has them switched on. The new Environment starts with the source's configuration and no people, keys, or assignments.

Export: on the source card's ⋮ menu click Export Configuration. A JSON file downloads and a success toast appears; nothing changes.

Import: on the target card's ⋮ menu click Import Configuration. The dialog warns that the import replaces the target's configuration. Drop or browse to the exported file, then click Replace configuration. A success toast appears, followed by a New secrets dialog that reveals the re-minted OAuth client and webhook secrets once; copy them before dismissing it.

Promote: on the source card's ⋮ menu click Promote Configuration to…. The Promote dialog warns that the target's configuration is replaced, not merged; pick another Environment in the same Application under Promote to and click Promote. A Promoted … toast appears, followed by the New secrets dialog for any re-minted OAuth client and webhook secrets.

Switch the Environment you are working in

Everything under Access Control belongs to one Environment at a time. Three controls choose it, and all three set the same active Environment.

Switch the Environment you are working in

On Applications, select an Environment's card. It becomes the active Environment and the switcher updates to match; selecting a card in another Application switches the Application too. Exactly one card is selected at a time, and you stay on the Applications page.

On Applications, click Access Control on an Environment's card. You land on that Environment's Access Control → Overview, and the pages beneath it show only that Environment's data.

From any Environment-scoped page, open the Application and Environment switcher, which sits in the left nav directly above Access Control, and pick another Application or Environment. You stay on the same page, now showing the other Environment's data.

On a production Environment, the identity pages open only for someone holding production_identities.access; everyone else sees a panel explaining the restriction rather than the people. The same grant governs everything that reads the audit log: the log itself, a directory's Activity feed and an SSO connection's recent sign-ins, where events about those people are withheld from anyone who does not hold it.

If you don't see this

Each control on the Applications page exists only for someone who may use it. When something described above is missing, one of these is why:

Applications is not in the left nav. Your administrator role does not carry applications.view. Every seeded Console role does; only a custom role can withhold it.

There is no Create Application, no gear menu, and the ⋯ menu is missing or offers only Publishable Key. You hold applications.view but not applications.manage; Publishable Key appears for anyone holding publishable_keys.view.

Delete Application is muted. It is the only Application in the Account. Delete Environment is muted for the default Environment and for the last one left.

Set as Default is disabled. That Environment already is the default.

The card has no Manage Levels item. Levels exist only on an Environment running the hierarchy model.

What an Environment holds and how the default works →

Enable and build a hierarchy →

Environment

API version

v1.0

On this page

Was this page helpful?

Tell us how we can improve this guide.