General Blocks

General blocks are basic blocks necessary to build a workflow. There are six general blocks in the system:

901
  • Start
  • End
  • Timer
  • Start on date
  • Task
  • Condition

Start

The Start block is required to create a workflow. It automatically appears in a new workflow by default. To add it manually, click the Start block icon on the left or drag it to the editor. There can only be one Start block in the workflow.

You can enable automatic checking of contacts participating in the workflow:

  • whether they participated in a certain event (for example, they signed up for a course and already received tutorial series);
  • whether they are in a certain segment (for example, it is necessary to cover newcomers with a campaign and not launch it on active buyers);
  • whether they made an order (for example, 7 days before the start of the workflow).

Workflow stops earlier, if a condition met. The check takes place at the workflow's start and after each Timer block.

The check switcher is placed in the right settings panel.

901

After enabling, specify the conditions for early stopping of the workflow for the contact:

  • By event;
  • If the contact is included in a segment;
  • Order-based.

Select one of the check types using the radio button.

End workflow by event

901

In the Exit on event drop-down list, select the event that will stop the workflow for the corresponding contact.

${eventKey} is the universal variable for the event key specified in the block by default. When the system starts a workflow, it checks the selected event: if it finds the event key, the workflow ends for this contact.

You can see the event unique key in the AutomationEvent History section.

1537

📘

Important

The event key (email, contact ID, etc.) must match in the event that started the workflow and the event that should end the workflow.

End workflow if the contact is included in a segment

904

Select a segment from the drop-down list in the Segment field. If the system detects that a contact enters a specified segment, it will stop the workflow for them. The system identifies contacts by one of the parameters:

  • phone number;
  • email;
  • conact ID in Reteno.

Order-based workflow end

898

The workflow stops if the contact has placed an order within the selected period before the workflow starts or any time after it starts. Set the time to check in the Period field.
The system searches contacts by one of the parameters:

  • phone number;
  • email;
  • conact ID in Reteno.

First, the system uses contact ID, if it’s not specified, then by externalCustomerId to search for a contact, if this is present in the event parameters.

End

This block is also required. It ends the workflow and can be used several times. All workflow paths must be ended with the End block.

Timer

The block is used to set a time gap before the following action or message sending. It is placed before a block you want to delay.

Contact confirmation triggers the workflow with a drip welcome series in the example. A new user receives a welcome email after confirmation, a second email after two days, and a third after the next three days.
To set up Timer, configure one of 2 or both parameters:

  • Wait time;
  • Wait until.

Wait time

Enter the wait time and select the parameter to which it will be applied:

  • minutes;
  • hours;
  • days;
  • months.

📘

Important

If you delay 1/2/3 days, the delayed action will start 24/48/72 hours after the workflow is triggered. If a person registers at 7 a.m., they will receive the first message at 7 a.m. the next day.

Wait until

Here you can select the day of the week and the time for sending.

If you set the sending time at 8:45 a.m. and the workflow starts at 3:00 p.m., the subscriber will receive the message at 8:45 a.m. the next day.

📘

Important

If today is Tuesday and you've chosen to send a message on Monday, the message will be sent next Monday. If it's Monday today, the subscriber will receive the message today.

Parameter Priority Example

You've configured the following delay parameters:

  • wait 1 day;
  • send on Monday at 8:45 a.m.

The workflow starts on Sunday at 3 p.m. The system waits for 1 day (24 hours). Then it's Monday. The Wait 1 day parameter expires at 3 p.m. on Monday. The system checks the Send parameter. You have chosen Monday, today is Monday, so far everything is fine.

The system checks Wait until. It’s set for 8:45 a.m., and the workflow is triggered at 3 p.m. The subscriber will receive the message not this Monday but only the next one at 8:45 a.m.
Configure the settings carefully!

Start on date

The block is used to send a message days/hours/minutes before the date and time you send in the event or set manually. If the start time is taken from the event, the transferred time zone is applied. If the start time is set manually, the block will start in the time zone specified in your personal profile.

In In, specify when before the date to send the message: 1 hour, 3 days, 10 minutes, etc.
In Before date, you can take the required date from the sent event. In the box below insert the parameter name from the event, for example, ${date}.

📘

Important

There are two supported formats for the date and time:

  1. UTC: 2011-12-03T10:15:30;
  2. UTC offset: 2011-12-03T10:15:30+02:00.
    The UTC offset is the difference in hours and minutes from UTC for a particular place and date. UTC+02:00 is used in some countries of Central Africa Time, Eastern European Time, and South African Standard Time. See the full list here.

Task

The block is used to set for the workflow one of the following tasks:

Confirm contact

The task is to confirm the subscriber's email address, add them to the system, and make them available for receiving emails.

For example, if a user fills in a subscription form, their email address gets to the Reteno system and they receive a confirmation email. They can not receive promotional campaigns until they confirm their subscription. A successful confirmation link triggers the task and starts the corresponding workflow.

The task has 2 parameters:

  • email: contains the variable ${EmailAddress} by default, so you don’t need to fill it. You only change it if you create your own variable that contains an email address.
  • contact_id: if contact is confirmed not by the email address but by the contact ID in the system, specify the variable's name that contains the contact ID. By default, it is ${ContactId}.

We recommend that you leave the default settings in this block. If your workflow needs adjustments, please contact support.

Create contact

The task is to create a contact in the system. If the contact with this email address already exists in the system, it will be updated.

📘

Important

Use this task only when the contact data is passed via the API method Generate event, and only a part of the data needs to be specified when a contact is created. For example, you sent the event via Generate event for a new contact. With this block, you add this contact to the system. For all other methods, this block is not needed.

The task has 3 parameters:

  • Contact’s email: required field. By default, it contains the variable ${email}. If your event has a different variable, specify it in the field.
  • Phone: required field if you create a contact by phone number. By default, it’s filled with the variable ${phoneNumber}. If you have a different name for the variable in the event, specify it in the field.
  • JSON: field contains a line or a variable with a line in JSON format with contact data (phone number, name, surname, city, additional fields). Email address is specified by default; if needed, specify other additional data.

Request body for the json field:

{"firstname":"...","lastname":"...","sms":"...","town":"...","timeZone":"Etc/GMT+03","languageCode":"uk","profileInputs":
[{"profileInputId":10001,"value":"..."}],"confirmed":false}

where

  • profileInputs - additional field array;
  • profileInputId - additional field ID;
  • value - additional field value;
  • confirmed - contact email address status (confirmed/unconfirmed).

Important!

To create an unconfirmed contact, add "confirmed":false to the request body:

{"firstname":"...","lastname":"...","sms":"...","town":"...","profileInputs":

[{"profileInputId":10001,"value":"..."}],"confirmed":false}

To create a contact with a value in the date field, use the format DD/MM/YYYY:

{"profileInputs": [{"profileInputId":10001,"value":"11/06/2011"}]}

To create a contact with a value in the date with time field, use the format DD/MM/YYYY HH:mm":

{"profileInputs": [{"profileInputId":10001,"value":"11/06/2011 16:42"}]}

Obligatory email

The task is to send an email to the contact regardless of their status in the system. With it, you can send an email to any email address (confirmed, unconfirmed, unsubscribed, spam report) except for blacklisted contacts.

📘

Important

Use this task only if necessary. It ignores the contact status, resulting in spam reports and harming the sender's reputation. Use the task only to send a transactional email (subscription confirmation, order confirmation, change in a pricing plan) to a new unconfirmed contact. In all other cases, use the task Email from the Actions blocks.

The task has 5 parameters:

  • EmailAddress: field for a contact’s email address or the variable ${EmailAddress}.
  • messageId: required field. Select a pre-created email from a drop-down menu or set the variable.
  • contactId: contact ID in the Reteno system. It can be used for contact identification instead of the email address.
  • languageParam: language ID or the event parameter containing it. It is needed to create multilingual messages. Leave the field blank if you don't use Multilanguage, or the language of the contacts is specified in their cards.

Event parameter example:

Language ID can be entered as follows:

  • en, es, fr;
  • EN, ES, FR;
  • en-US, fr-CA, en-AR.
  • jsonParam: random data in the JSON format passed to the email. If you pass a line with such data in the event, specify the parameter name in the JSON field. For example, you pass the order data, and you need to list the ordered items in the email. The request body would look as follows:
{

"name": "items",

"value": "{\"array\":[{\"name\":\"Women's Grand Court Sneaker\",\"price\":\"341.00\",\"url\":\"https://site.com/catalog/Womens-Grand-Court-Black\",\"imageUrl\":\"https://site.com/uploads/product/big/20161122/20161122_7zvb.jpg\"},{\"name\":\"Women's Cloudfoam Advantage Cl Sneaker \",\"price\":\"78.00\",\"url\":\"https://site.com/catalog/Womens-Advantage-Sneaker-Metallic\",\"imageUrl\":\"https://site.com/uploads/product/big/23112013/2125.jpg\"}]}"

}

The example contains items. Accordingly, in the JSON field, ${items} is specified.

Create promo code

The task is to create (generate) a promo code and pass it to a message that goes next in the workflow. The algorithm will encrypt the parameters by your key, and another algorithm will decrypt it when the promo code will be entered on the website. Learn more.

The task has 4 parameters:

  • days: number of days until the promo code is expired. The system will add them to the current date, and the resulting expiration date will be encrypted into the promo code.
  • type: promo code type. You can set up 32 promo code types. For example, assign type 0 to a subscription promo code, type 1 to a birthday code, type 3 to reactivation code, etc. Pass in the variable the number from 0 to 31 that corresponds to the right type.
  • discount: the amount of discount. Used to generate a promo code when a discount is given as a % off the order cost. It is always a double-digit number, so discounts of up to 10% should go with zero ahead. For example, specify 05 for a message with a 5% discount.
  • key: encryption key. You can leave the default value.

📘

Important!

All parameter fields are required.

In a workflow, this block is followed by one of the Actions blocks (Email, SMS, Mobile push, etc.). For example, in the email template, you can put a variable $!data.get ('promocode') in the place intended for a promo code.

Update contact

The task is to update the contact information. If the contact exists in the system, their info will be updated; if the contact doesn’t exist, the system will skip them.

Use this task to update the contact data from an event sent via the API method Generate event, or to set a fixed value of the additional field in the workflow.

The task has 4 parameters:

  • ContactId: if contact is updated not by the email address but by the contact ID in the system, specify the variable's name that contains the contact ID. By default, it is ${ContactId}.
  • Contact’s email: specify the variable from your event in this field. In the system events, the variable is called EmailAddress. System events are the events generated within the system (click on an email CTA, regular workflow launch, filled subscription form, reactivation with RFM analysis). For them, enter ${EmailAddress} in the field.
  • Phone: required field if you update a contact by phone number. Specify the variable ${phoneNumber} in the field. If you have a different name for the variable in the event, specify it in the field.
  • JSON: field contains a line or a variable with a line in JSON format with contact data (phone number, name, surname, city, additional fields). Email address is specified by default; if needed, specify other additional data. The parameter confirmed is ignored.

Get order

The task is to extract the data out of order and pass it to the message. It can be used in workflows that include transactional messages (order confirmation, delivery, etc.). Use the task only if you send order data to Reteno via the API method Add orders. More details on order automation.

The task works as follows:

  1. Order information is sent to the system.
  2. The task extracts all the data that goes with the order.
  3. Block passes this data to the message in the form of variables.

You don’t have to fill any fields for this task. All parameters are automatically taken from the order event.

Launch event

The task is to launch any event from the workflow. For example, one workflow can trigger the launch of another. You need to previously create the event you plan to launch to use the task.

The task has 3 parameters:

  • eventTypeId: required field. Select the type of event to launch.
  • keyValue: key of the event you’re launching, for example, a variable with an email address. If the field is not filled, the key from the event that triggered the current workflow will be used.
  • params: array of parameters we want to pass to a launched event. If the field is not filled, the parameters from the event that triggered the current workflow will be passed.

The format of the parameters:

[{"name":"paramName,"value":"parameter value"}]

Get contact

The task is to get contact data and pass it to the message or the Condition block. For example, you want to send a notification with contact data every time a new user is added to the database, or send registration details after registration.

The task works as follows:

  1. The event that contains contact data is created (registered) in the system.
  2. The task extracts all available contact data stored in the database.
  3. Block passes this data to the message.

The task has 4 parameters:

  • ContactId: contact ID in the Reteno system;
  • EmailAddress: email address of the contact;
  • Phone: phone number of the contact;
  • MobPushToken: mobile token of the contact.

EmailAddress, ContactId, Phone, and MobPushToken are used to identify a contact. One of these fields must be filled with relevant data.

For example, if you want to identify a user not by email but by ID in the system, specify the variable's name that contains the contact ID. By default, it's ${ContactId}.
You can use these variables in the message:

  • $!data.get('firstName') - name;
  • $!data.get('lastName') - surname;
  • $!data.get('email') - email address;
  • $!data.get('sms') - phone number;
  • $!data.get('contactKey') - contact key;
  • $!data.get('id') - contact ID in the system;
  • $!data.get('createdDate') - creation date;
  • $!data.get('updatedDate') - date of the last contact update;
  • $!data.get ('confirmed') - contact’s email address status (true - confirmed, false - not confirmed);
  • $!data.get('fields').get('12345') - additional fields. Insert an ID of the additional field instead of 12345.

Get promo code

The task is to pass a promo code from the base to the message. More about uploaded promo codes.

The task has 3 parameters (all are required):

  • days: number of days after the current date during which the promo code is valid;
  • type: promo code type;
  • discount: discount amount from 01 to 99.

Based on them, the system selects promo codes from the loaded list.

For example, we have the following parameters: days - 10, type - newyear, discount - 25. The workflow will extract from the newyear segment a promo code with a 25% discount that is valid for at least 10 days. If several promo codes meet these criteria, the system will choose one of them.

In a workflow, this block is followed by the message sending block (Email, SMS, Viber, etc.). In the email template, put a variable $!data.get('promocode') in the place intended for a promo code.

Condition

The block is used to check whether certain workflow conditions are met or not. Depending on this, the workflow is further split into two paths - Yes or No - with different tasks.

The block has one Start block and two End blocks (for Yes/No paths).

The Condition block has 7 tasks:

Check event is a default task. When needed, choose the necessary task from the drop-down menu.

Check event

The task is to check whether a particular event occurred since the workflow was launched. Events are searched by keys.

The task has 2 parameters:

  • key: event key. For example, it can be an email address; thus, this field should contain a parameter with an email address. If it's EmailAddress, enter ${EmailAddress} in the field.
  • type: event type. This is a required field without which the workflow will not start.

Variable matches regular expression

The task is to check a certain variable from the event or the data received from other blocks.
For example, you can check who your recipient is - male or female - and send them different messages.

The task has 2 parameters:

  • name: variable name. It could be an event parameter. The parameter name is entered in this field without ${}. If you check the data obtained by other workflow blocks (for example, Get contact), specify the system variable smartMessageJson in the field.
  • pattern: regular value checked for compliance. For example, to check whether the event parameter address contains the word “London”, specify .*London.* in the pattern parameter.

Contact confirmed

The task is to check whether the contact's email has been confirmed.

For example, a person has subscribed to your newsletter, and you want to send a welcome email.
The task works as follows:

  1. The contact is added to the Reteno database but has an unconfirmed status.
  2. A confirmation email is sent to the contact.
  3. The task checks whether the subscription is confirmed.
  4. If it is confirmed, the Yes path is triggered, and a welcome email is sent.
  5. If it isn’t confirmed, the No path is triggered.

The task has 2 parameters:

  • EmailAddress: contact’s email address;
  • ContactId: contact’s ID in the system.

By default, the system uses the variable EmailAddress with the email address to check whether the contact is confirmed. If the event variable is called different, specify ${event variable name} in the parameter field, for example, ${MailAddress}.

If you want to use a contact ID for confirmation, specify ${ContactId} in the ContactId field.
One of the parameters must be specified.

Contact exists

The task is to check whether the contact exists. It works similarly to Contact confirmed.

The task has 3 parameters:

  • Contact’s email;
  • Phone;
  • Contact ID.

By default, the system uses an email address. If you want to use a contact ID, specify ${ContactId} in the ContactId field.

Check parameter by date/time value

The purpose of the task is to check the date from the event parameter.

When creating a workflow, the user's time zone is taken into account, the time will be saved in UTC.

For example, we check the date with the time 2020-07-30 13:00. The user's time zone is (GMT +3) Europe/Kyiv, respectively, 2020-07-30T13:00+03:00 will be transferred in the event.

📘

Important

Pay attention to the time zone and take into account the daylight saving time

  • Parameter name - you must specify the value of the parameter that is transferred in the event. The required date format is ISO 8601.
  • Date - you must select a specific date or range of dates from the drop-down list.
  • Select a specific date.

Check contact field is equal to parameter from event

The task allows you to check if the contact field matches the transferred value in the event parameter. For example, you want to check if the user's city matches the city value transferred in the event. If not, you can use a contact update block after this block.

The task has 5 parameters:

  • Contact ID;
  • Phone;
  • Contact’s email;
  • Contact's field - the field from the contact card, the compliance of which needs to be checked. You can select from a drop-down list or by using the search bar. The fields of the following types are subject to comparison: text field, text area, number, fractional number, drop-down list;
  • Event parameter, for compliance with which we check the contact field. The value can be specified as a variable ${parameterName} (parameter name in the event, for example, ${city}). In this case, the contact field specified in Contact's field is compared with the value from the specified parameter in the event. You can also specify a string in the format 123abc (for example, London) - then the contact field is compared with the specific value specified in the parameter (that is, is Contact's field equal to 123abc?). Select the appropriate check box below this field if you want the operation to be case-sensitive when comparing.

The first three parameters are used to select how the contact is identified. For the task to work correctly, one of these fields must be filled in with the appropriate data. For example, if you need to identify a user by ID in the system, you need to set the ${ContactId} variable. The fields can be left empty if the Check contact field is equal to parameter from event block is preceded by the Get contact block. In this case, the contact will be identified by the identifier specified in its settings.