Configuration Driven Integration
In this quickstart we'll look at how you can use several types of config variables and connections to drive logic in your integration. This helps to illustrate how your consumers can have instances of the same integration deployed to them, with different configurations.
Basic config variables
The most basic type of config variable is a simple string. A string config variable can have an optional default value, and you can add Description helper text to indicate to your end user what type of string the config variable expects.
For example, we can create a config variable that prompts the user for their API endpoint:
When your user configures an instance of the integration, they're prompted for the string and they're provided the helper text you added:
You can use the string that your user entered as an input for one or more steps:
Or, you can concatenate the string together with other static strings, config variables, and step results, to generate dynamic inputs for steps:
Creating dropdown menus and branching from options
If you'd like to limit the options an end user can choose from, select picklist as your config variable data type. You can generate a list of options that your user can choose from:
When deploying an instance of the integration, your user will see a dropdown menu with the options you created:
These config variables can be used like you use string config variables (above).
You can also drive branching logic from a picklist by adding a branch for each picklist option.
Prompting for lists of values
Sometimes it's handy to have a user enter one or more values for a config variable (think "arrays" in JavaScript or "lists" in Python). Create a config variable, and select List as the Config Var Type.
Users can enter one or more values for the config variable
If you reference that config variable in steps of your integration, the code backing your step will receive an array of strings rather than a single string.
Branching on boolean config variables
You may want to prompt a user with a "yes/no" question, and drive some logic based on their answer. First, create a boolean input.
The end user will see a simple toggle in their configuration wizard.
Create a Branch on Expression step, and have one branch run if the value "is true" (otherwise, it'll follow the other branch)