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 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, roles and their permissions, 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 note lists what is copied. The new Environment starts with that 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.

Switch the Environment you are working in

Everything under Access Control belongs to one Environment at a time. Two controls choose it, and both keep you on an Environment-scoped page.

Switch the Environment you are working in

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 switcher at the top of the left nav 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.

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 no ⋯ menu. You hold applications.view but not applications.manage.

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.