Environments Environments

Environments

Ismaen Aboubakare Ismaen Aboubakare

Environments provides the capability to separate integrations, resources, APIs, and tokens within an organization. Environments serve as a container to organize these resources and allow builders to silo them based off of their use case. Every organization comes pre-provisioned with three default environments: DEV, STAGING, and PROD. These environments can then be used to assign resources to their respective environment, which can then be tied to a specific application using profiles.

mceclip4.png

This article will cover the following:

Assigning a resource to an environment

When creating an integration, resource, or API in the console, builders have the option to select the environment in which it will be accessible in.  For example, when adding an integration, there is the option to select the environment that the integration will be created in.

mceclip1.png

By creating the integration in the DEV Environment, the integration will only appear as a selectable option if the DEV environment is selected in Configuration Builder.  To select the environment, go to Configuration Builder > Global and select DEV in the Environment dropdown. 

mceclip2.png

Then when adding the integration, the integration should be accessible in the list of options. 
mceclip3.png

Environments and Profiles

It is considered best practice to have your profiles and environments aligned. For example, the development profile should have the DEV environment configured, QA profile with the STAGING environment, and the Production profile with the PROD environment. By default, the environments are tied to their corresponding profiles, but you do have the option to change them. If changed, the resources will need to be reselected after switching.  

 

Was this article helpful?

0 out of 0 found this helpful