Passing Workflow variables to Designer

Runtime parameters

Passing values from Workflow to an OL Connect template, data mapping configuration or Job Creation Preset can be super useful. For example, when you want to:

• Read URLs and paths for links and resources from global variables
• Load different sections or snippets depending on a variable in the workflow
• Control the position of objects depending on a variable in the workflow (e.g. position the address block depending on the printer)

This is what runtime parameters are for. Runtime parameters pass variable values from Workflow to either a template, data mapping configuration or Job Creation Preset directly, without adding data to the data records. They have been introduced gradually in OL Connect, in these versions:

2019.2 – in Job Creation presets (with the Job Creation and All In One plugins)
2020.1 – in data mapping configurations (with the Execute Data Mapping and All In One plugins)
2020.2 – in templates (with the Content Creation plugins)
2021.1 – in scripts and conditional rules

In the Online Help you will find instructions on how to use them: Runtime Parameters.

Passing variables via the data record

If you are working with an older version of OL Connect, runtime parameters are not available. You can, however, use the following 2-step trick to get Local and Global variables from Workflow into your data record and then use them in your template.

Step 1 – Define the variable in the Preprocessor Step

Though variables are “passed on” to the data mapping task automatically, you need to declare them in your data mapping configuration for them to be useable. To do this, simply click on the Preprocessor step in the Steps pane, then look at the Properties section. Click Add Property. In the property’s definition, you need 3 important things.

• First the name, which must correspond to the name of the variable in Workflow. Both local and global variables are called the same way, with their name as it’s displayed in the Resources pane of Workflow. Local variables have priority so if you have a local and global variable named the same, the local one is used.
• Second, the scope which has to be set to Automation variable.
• Third, the default value, which is useful to test your data mapping and template with just a static value that’s replaced at runtime.

Step 2: Add the value to your record

Adding a property to your record is done through a very simple script. Here’s how you do it:

1. Open an Extraction step that is not within a loop, or create a new one.
2. Click the Add Javascript Field button next to the Field List drop-down.
3. In the Expression, type in the appropriate variable name preceded by automation.variables. , so if you have an automation property declared as my_var , you’d get automation.variables.my_var;
4. Rename the field in the Order and Rename Fields dialog (next to the Field List drop-down).
5. Save the configuration.

From this point on, the Template that uses this data mapping configuration has access to the variable added to the data model. Of course, you will only see the default value at this point, the actual value will only be available once the data mapping configuration and template run in Workflow.

Job Infos, no data mapping required
One last thing to note: it’s wholly possible to use JobInfos without having a data mapping configuration loaded. This is only true for Web contexts, when using 0 as the Record ID in the Create Email Contents task. However, these can only be used in scripts, using automation.jobInfos.JobInfo1 to automation.jobInfos.JobInfo9.