Environment Specific Settings

Context

Some Content Hub implementations require the need to store some values that are specific to a particular environment, such as integration URLs, or feature flags. The ideal place for these is an environment specific setting; they aren't particularly well known but are super useful and are exactly what we need here. When exporting settings from the Content Hub environment, settings marked as being environment specific are excluded during the package import, meaning you can safely deploy between environments without fear that these values will be overwritten.

Execution

A clear use case for this is as described in the Single-Sign On recipe, where based on the environment in use (DEV, UAT, PROD), a different AD group mapping might be required.

Create a Setting Entity

As environment specific settings cannot be created using the UI, we can instead use the API. To do this create a HTTP POST request to /api/entities with the following body:

create-setting.json

Setting the M.Setting.EnvironmentSpecific property to true is crutial. This, as mentioned earlier, is not exposed through the UI and can only be set on creation (I.E. it cannot be updated later). Once created though, the setting can be managed in the same way as any others in the Manage > Settings section.

You will of course need to replace the tokens with your own specific values, and either choose an existing Setting Category or create a new one.

Create a Setting Entity

Creating a new Setting Category is very similar to creating a Setting. Simply create a HTTP POST request to /api/entities, this time with the following body:

create-setting-category.json

You will need to replace the tokens with your own desired values. The API will respond with a JSON payload containing the id and identifier of your newly created Setting Category which you can use to create a Setting.

Insights

So now we know how to create environment specific settings in Content Hub, there's a few use cases where this can be used.

External Components

Where you have external components which connect to external systems, there may be a need to connect to a relevant instance of that external system depending on the Content Hub environment. For example, the production instance of Content Hub should call api.someservice.com, but the dev instance of Content Hub should call dev.api.someservice.com. In this case the url should be stored in an environment specific variable, which is fetched within the external component.

Scripts

There may also be cases where scripts should operate differently based on the environment. For example, you may have a script which automatically creates public links for assets. In production, it should create the public link, but in non-production environments should simply create a log.

Post Deployment

A common use case of environment variables in a script is to update various entities such as actions and external components with environment specific values after a deployment. Further detail can be found in the Multi Environments Deployment recipe.

Related Recipes

Related Documentation