After reading this article, you'll know:

Configurations can be used for a variety of things within the platform. They can be seen as a 'global' variable of some sort. Configurations allow you to reuse a value in multiple places, like in multiple action steps. But if that value changes instead of having to re-adjust that value manually in those action steps, you can simply change the value of the configuration and it'll be changed in all the steps where you've used the configuration in. Configurations can also be used to store stuff like login details or API keys.

Configurations are environment dependant, which means that if you have an application that uses sandboxes. The configurations for each sandbox are tied to that sandbox so when you merge your sandbox a sandbox above it will not merge the configurations.

Let's start by creating a basic configuration.

1. Open the tools menu (1) from the builder bar and pick up the configuration (2).

2. You can create a new configuration by pressing the New button (3).

3. A slide-out window is opened where you can specify the details for the configuration: name and value. You also have the option here to choose what kind of configuration you'd like to create. A single configuration contains just one value but if you want to create a configuration for, for example, your email then a set might fit better. You can add multiple values to one set and use that within your actions etc.

The send email step used below can be installed from the block store.

You can make use of configurations when working with emails. You probably don't want to manually fill in the host, port, username, and password values in, for example, 6 email steps when one of those values changes. Creating a configuration for this instead, and updating that when a configuration changes so that it'll automatically be applied to those 6 steps is a better approach.

Go to the configurations section located within tools.

You can create single configurations, but in this use case creating a set is cleaner, this allows us to keep our configuration overview a bit tidier. Configure the Email configuration like below.

Note that the port number isn't here, that's because configurations are strings or in other words text, so if we were to add a port number it would be greyed out when we try to select it.

Another nice feature is that we're able to encrypt values. So in this case encrypting the password is a nice thing to do - we don't want everyone with access to the configurations to see this. Encrypting values is also super nice whilst working with API's ensuring that the data and keys etc. that are sent back and forth are not publically visible. As shown in the images above when you decrypt a value, it'll instantly be erased in order to make sure our sensitive data is kept safe.

With the step properly configured, it should work like normal. When we run the action in the playground, an email should be sent.

And voila, our test mail to see if the action step works while using configurations seems to work just fine!

Configurations are meant to set sandbox-independent values, so you can set different values for the sandbox. After merging your API user name (for instance, HighQ has a production environment with different endpoint credentials and API keys), the sandbox wants to communicate with the production environment (of the HighQ API). You merge it and you have to set the value for the sandbox manually (e.g. 'True' or 'False' values).

Afterward, you need to merge a sandbox and update the configuration. Otherwise, your application might break.