Data input and output: Input variables and context variables

To understand this topic, you'll first need to learn the difference between an input and an output.

An input is information that will be put into Rewst automations. This could be the contents of a form, or information sent via integration, for example. Knowing what your input is will help you determine what to use when crafting your automations.

An output is the expected result of the automation.

Workflow input: Input variables

Workflow inputs are commonly known as input variables. The role of input variables is to provide data that can be used by tasks within the workflow, or into a subworkflow.

Input variables can be broken down into two parts:

1. A key

2. The specific data or values that vary

This is an example of a variable where [first_name] is the key and Ashley is the value:

[first_name] : "Ashley"

Input variables can only be modified or added on the source workflow, not clones of workflows unpacked from Crates.

You can add new variables, or modify existing ones, by navigating to your Workflow > Configure Workflow Settings > Input Configuration.

Click + next to Input Configuration to see a number of new fields.

1. Name: This can be a unique entry relevant to what the aim of the input is going to be. This should not contain spaces.

2. Label: This text field is used to set a friendly name. It's the field name visible at the time of input.

3. Type: Short for data type, this field defines what format the data will be in. The most common types are Text (general string), Integer (whole number), and String (a combo of characters).

4. Default Value: You can specify a value that will be used if no other input is specified manually.

5. Description: You can give a better description of what the field is used for.

Input variables get their values in a Rewst workflow through the workflow's initial trigger event. Any data type that is valid in JSON can be used as an input variable.

An example of an input variable, using static data

Workflow action inputs

When variables are created within the workflow, they become Context Variables, and can be used directly in action inputs.

Recall from your Cluck University training that the context is where all data generated, captured, or used in a workflow is stored.

In the example below, creating a user in Microsoft 365 using three variables:

1. First Name

2. Last Name

3. Domain

For now, these are all specified directly on the workflow rather than being submitted via a form.

Create an action by dragging it from the integration list on the left menu.

Click on this action to reveal a number of input fields on the right-hand side.

Click to the right of the field to open up a Monaco editor, the same type that VSCode uses. Learn more about the code that Rewst uses, called Jinja, here.

In the image below, see how to use the variables by using CTX, which stands for context, and then the name of the variable. This will autocomplete to make it easier to reference.

{{ CTX.first_name }}
{{ CTX.last_name }}
{{ CTX.domain}}

Despite the data being static at this point, the process is the same regardless of where the data is coming from.

Workflow output

Similarly to the above, you can configure an output of a workflow. These are generally used in two situations:

1. In an Options Generator workflow, the output is what is passed through to the form. For example, if you have a workflow that lists users in a variable called {{ CTX.users }} - you would configure an output variable of options mapped to this variable, as per the below image. This then, in the form, would list the users in a dropdown field. This is how dynamic data works in form - more about that in types of workflows.

1. The other time this would be used is if you have a sub-workflow. A sub-workflow is no different from a standard workflow, except for the fact it lives within another workflow. If you were passing data back from the sub-workflow into the main workflow, this would be done via an output variable.

Workflow action outputs

One of Rewst's ultimate purposes is to integrate various platforms into a workflow and use data from each to do something else.

In this example, you'll get a list of users where the userPrincipalName matches X, then create a ticket using information from that request.

First, take the action of List Users from the Microsoft Graph integration in the action menu of the workflow builder. There are no inputs required here, and it will list every user on the tenant that it is integrated with, or that the trigger is set for.

If you ran this action as-is, you would get the list of users, but wouldn't be able to use that data anywhere.

This is where Transitions come into play.

Click the On Success transition on the action. This gives you the option to create a data alias.

A data alias allows you to create a variable, similar to an input variable, but with data direct from an action API request. In our example below, we are creating a variable with the key called user_details and populating it with the data of the user using Jinja.

{{ [ user for user in TASKS.m365_list_users.result.result.data.value if user.userPrincipalName == "[e-mail]" ] }}

Take your create_ticket action from your respective PSA from the actions menu of the workflow builder. In this example, we'll use Datto PSA.

Using your newly created data alias, add the inputs onto that create_ticket input.

User Exists {{ CTX.user_details.displayName }}

This would create a ticket with the title User Exists [e-mail].