Automation inserts
You can use Jinjava in Automation to provide context or work with parameters.
When another journey in the Automation requests a result of the same analysis in that period, the cached definition is used to calculate the results. This means that if you edit a segmentation, aggregate, or expression used in an Automation, it takes 20 minutes for the new version to start being used in journeys.
This includes definitions of segmentations, expressions, and aggregates nested in other analyses and used in Inserts.
You can find the snippets in our Github repository: https://github.com/Synerise/jinja-code-snippet
Where can Jinjava be used in Automation?
- All action nodes
- Outgoing integrations
- Templates of communications sent from Automation
- Profile filters
- the Audience node
Common tags available in Automation
You can use all tags from Insert usage.
Profile attributes
Profile attributes in automation can be retrieved in two ways:
- using the
{{ customer.attribute }}
syntax. If the attribute does not exist, an empty string is used in its place.
If the attribute name contains special characters, use{{ customer['attribute'] }}
- using the
{% customer attribute %}
syntax.
If the attribute does not exist, the insert isn’t rendered and the node isn’t processed (for example, an event isn’t generated, a webhook request isn’t made).
This syntax does not allow special characters in attribute names.
Event parameters
Event parameters store additional information, such as og:tags. Some of them are required, but you can also create custom parameters. When you use the syntax below, the parameters are retrieved from the event that is the current context.
Syntax:
{{ event.<parameter> }}
If the property name contains special characters, use {{ event['<parameter>'] }}
You can use dot notation to access properties nested in objects.
Example:
Event saved in the database:
{
"createDate": 1695989087498,
"action": "product.addToCart",
"params": {
"source": "MOBILE",
"finalUnitPrice": "3.25",
"brand": "exampleBrand",
"revenue": 9.75,
"eventCreateTime": "2023-09-29T12:04:47.498322032Z",
"ip": "13.93.68.194",
"quantity": 3,
"sku": "189784563455",
"currency": "USD"
}
}
Examples of output:
{{ event.action }}
outputs"product.addToCart"
{{ event.params.sku }}
outputs"189784563455"
Context
The context is the most recent Trigger or Event Filter node.
You can change the event context within a workflow by putting an Event Filter before the node that includes a reference to an event parameter.
Context switch example
If you want to include an outgoing integration node and use parameters from the response:
-
Add an outgoing integration (webhook) node.
-
After that node, add an Event Filter node:
- Set up the filter to wait for a period of time.
This is to avoid getting a profile stuck in a workflow if the webhook does not respond or returns an error. - As the event to filter by, use
webhook.response
. - Add a condition to the
webhook.response
: thename
attribute of the event must be the same as of the node with the outgoing integration.
This is to allow the profile to have more than one journey active at a time, with different webhooks being used.
Result: After this node, the context changes to the
webhook.response
event. - Set up the filter to wait for a period of time.
-
Insert an action node that uses a param from the webhook response by using
{{ event.params.param }}
.
Manually specifying the context
You can ignore the default context and refer to parameters of a specific Trigger or Event Filter node.
Syntax:
{{ automationPathSteps['nodeName'].event.params.paramName }}
If the param name contains special characters, use {{ automationPathSteps['nodeName'].event.params['paramName'] }}
The name of the node must be unique and cannot contain any special characters. The name is entered here:
Data context
The tag allows referencing the context of data retrieved through nodes that fetch data (e.g., Get Statistics, SFTP - Get File), and then using this data in:
- Integration nodes which don’t require a data input file
- SMS Alert nodes
- Email Alert nodes
The data is accessed as rows. You can retrieve up to 10000 rows.
Syntax:
{% datareference node='nodeName' maxRows=10000 %}
{{ datareference_result}}
{% enddatareference %}
where:
node
is the name of the node whose data you want to access.maxRows
(optional parameter) is the number of rows you want to retrieve. The default is 10000.datareference_result
is the list of data rows. You can iterate over this list (see example below).
The column names are case-sensitive. For example, if the column name isproductName
and your insert usesproductname
as a reference, it renders and empty string (""
).
Example
In this example:
- The automation is set to run once a day.
- The “Get statistics” node generates the statistics of yesterday’s email campaigns.
- The “Upload data to a spreadsheet” node uses the
datareference
insert the statistics to a spreadsheet.
In the “Upload data to a spreadsheet” node:
- As the Dimension, select Rows.
- In Values, paste the Jinjava that loops over the results of the “Get Statistics” node:
The[ {%- datareference node='Campaigns sent yesterday' maxRows=10 -%} {%- for r in datareference_result -%} ["{{ r.campaignHash }}", "{{ r.campaignTitle }}", "{{ r.campaignType }}", "{{ r.clickCount }}", "{{ r.clickRate }}", "{{ r.openCount }}", "{{ r.openRate }}", "{{ r.sendCount }}", "{{ r.sendingTime }}", "{{ r.uniqueCappingCount }}", "{{ r.uniqueSendCount }}", "{{ r.utm.campaign }}", "{{ r.utm.content }}", "{{ r.utm.medium }}", "{{ r.utm.source }}", "{{ r.utm.term }}"] {%- if not(loop.last) -%},{%- endif -%} {%- endfor -%} {%- enddatareference -%} ]
{%- if not(loop.last) -%},{%- endif -%}
condition prevents adding a comma after the last row.Important:- The Jinjava doesn’t create column headers.
- Column names are case-sensitive.
Aggregates
If an aggregate includes dynamic values (for example, from an expression or another aggregate), you must create an expression from that aggregate and refer to it in the automation using the expression tag.
For example, if you want to send an email with a satisfaction survey after a profile makes a transaction, it is better to trigger the automation with that transaction and use its ID as a param than to retrieve the ID using an aggregate that points to the latest transaction.
Managing parameters with schemas
If you use an outgoing integration in the workflow, that integration must use a schema. The schema dictates the kind of data that must be provided to the outgoing integration.
You can fill in the fields in the integration with variables from the profile/event context, but also with other data available using Jinjava, such as aggregate or expression results.
Using schemas and outgoing integrations is more convenient than manually entering the payload with variables in a node definition, especially in webhooks that are re-used often, have large payloads, or many variables in the payload.
Syntax:
{% context fieldId %}
fieldId
is the unique ID of the field, not the label used as the name of the column on the UI.
Example
The following example is a POST webhook that updates a profile’s name in an external database.
-
Create a schema for profile data. One of the fields is the profile’s ID in an external database, the other is the profile’s name.
Note: This schema doesn’t need to store any records. In this example, it is used only to define the data from a profile that must be entered in a webhook. -
Create an outgoing integration that uses the external ID in the URL and includes the updated profile’s name in the payload.
Example payload:{ "newName": "{% context customer-name %}" }
-
Use the outgoing integration in an automation workflow. You can now use the context of the workflow to fill in the data in the webhook.
Result:
For a profile whoseexternalId
attribute islue42
, the node makes a request tohttps://example.com/customers/lue42
, and thefirstName
attribute is included in the payload.
Workflow metadata
You can insert properties of workflow and the current step (a step is the occurrence of a profile entering a node in the progress of a workflow).
Syntax:
{{currentStep.PROPERTYNAME}}
The available property names are:
Property | Description |
---|---|
journeyId |
The unique ID of the workflow where this step occurred If the Profile has a workflow in progress and enters it again, journeyId is the same, because it’s the same workflow. A new ID will be generated if the workflow ends and then is triggered again. |
actionId |
Unique ID of this step (NOT the unique ID of a node. Steps only exist when the profile progresses through a workflow, and their IDs are different for each workflow) |
businessProfileId |
Workspace ID |
diagramId |
ID of the workflow definition |
clientId |
ID of the profile |
clientUUID |
UUID of the profile (may change, for example due to switching devices or browsers) |
You can use the insert in:
- Request URL
- Query parameters
- Request headers
- Request body
- Login or password (in the Basic access authorization method)
Example:
- You use automation to send data to an external system with Outgoing Integrations.
- You add a
deduplicationKey
header and set the value to{{currentStep.journeyId}}
. This inserts the unique ID of the journey into the header. - Your external system can use
journeyId
to recognize requests from the same workflow and perform deduplication.
Audience node syntax limitations
"
is forbidden as it will be misinterpreted by Jinja, use'
instead- If you want to use the
IN
operator in the conditions to check if a string occurs in an array, you must join the array by usingjoin('","')
, for example:It’s the only case when{% set arr = [] %}{% do arr.append('6678347477') %}{% do arr.append('4551874894')%}{{ arr | join('","') }}
"
is allowed