The Scenario wizard provides a visual canvas for building communication logic with contacts through dragging and dropping blocks and connecting them with communication lines.

To create a scenario, go to Mailings ➔ Scenarios. Once the name of the scenario has been set, you will be taken to the canvas on which you need to place the blocks.

On the canvas you can find various tools that can help you when working:

• Canvas movement/object selection modes (V)
• Undo and redo (Ctrl+Z and Ctrl+Shift+Z)
• Zooming - using the mouse wheel (Ctrl+scroll) or the magnifying glass in the bottom menu.
• Full screen mode (Ctrl+O)
• Show/Hide Scenario Preview (Ctrl+M)

In addition to the navigation tools, several other useful functions are available:

• Download scenario in image format
• List of all hotkeys

Block settings are on the right sidebar. Drag a block onto the canvas and double-click to open the settings.

It is mandatory to create at least one starting and ending block for each scenario. The rest of the blocks can be combined at your discretion and tasks.

The starting block is the event that must occur for the contact to start going through the scenario. You can use multiple starting and ending blocks within a single scenario. An important setting for the initial block is “Duplicate Handling”. It regulates the behaviour of the scenario in case the same contact starts the scenario without having completed the previous walkthrough yet. Be careful, because if you use several initial blocks, this setting will be synchronised and applied in each of them.

Starting blocks

• subscription - start the scenario when subscribing from the site, by API, via contact import, segment, contact card or after permission to send mobile push notifications
  • for a specific mailing group - the contact will start the scenario when he subscribes to the selected mailing group.
  • for a segment-specific mailing group - the contact will start the scenario when he/she subscribes to the selected mailing group and if he/she fits the conditions of the selected segment (the segment check will take place at the moment of subscribing to the group, i.e. when the scenario starts).
  • to any segment-specific mailing group - the contact will start the scenario when he/she subscribes to any of the mailing groups created in the account and if he/she fits the conditions of the selected segment (the segment check will take place at the moment of subscribing to the group, i.e. at the moment of scenario start).
  • on Mobile Push - the contact will start the scenario when he/she allows sending mobile push notifications in the application
• message - click (on any or specified link) or open the selected message
• API - getting an API request to start the scenario with preliminary checking of the contact for compliance with the conditions of the selected segment (segment selection is optional)
• data change -
  • start when the contact's custom field is changed to any value other than the current one or to the specified one
  • start when the contact's email is changed to any value, gets filled or empty (if the contact's previous email was deleted).
• schedule - start according to the specified schedule with obligatory checking for compliance with the segment (the contact will start the scenario only if it matches the conditions of the segment).

Main blocks

• message sending - available channels: Email, Mobile Push, SMS, WhatsApp. Read more about creating scenario messages here;
• pause - waiting before the next event, waiting for a specific date;
• distribution
  • by segment - the contact will follow the path of the segment whose conditions it matches. If the contact fulfils the conditions of several segments - it will follow the branch of the first suitable one;
  • by scenario field - contacts will follow the branch that matches their value in the scenario field. If a contact matches the conditions of several branches at once, it will go to the first branch that matches;
  • equal - contacts will be divided into equal groups according to the number of configured branches;
  • proportional - contacts will be divided in the ratio you customize according to the specified number of groups (scenario branches).
• data change - the value of the selected custom field of the contact passing through the block will be changed;
• API request - specify endpoint, request type, headers, set parameters and body (you can use DK)

Finishing block

• the first configuration option does not perform any actions with contacts
• re-subscribe to mailing groups - when the scenario is completed, the contact can be unsubscribed from mailing groups and subscribed to mailing groups. You cannot select the same group in unsubscribe and subscribe.
• delete contact - when the scenario ends, the contact will be deleted and can be restored in the deleted section.

By default, the scenario start request will only work for a contact that already exists in the database (similarly, a deleted contact will not be restored and will not start the scenario). The settings of the “API” starting block will allow you to pass a new contact (doesn't exist in the database) to the scenario (it will be created, if it was not found and the scenario for it is started).

How the contact creation setting works:

• if the checkbox is active, new and deleted contacts will be automatically created/restored and start the scenario, this does not require a separate request to create contacts before starting the scenario;
• the checkbox is configured for each API block separately, so there can be several “API” starting blocks in one scenario, both with active creation setting and inactive.

.

Rules for creating new contacts via API starting block

When the creation setting is active, any contact sent by API request is first of all checked for existence in your account database. If the contact was not found in the database, it is then checked for its presence among the deleted ones, and if no matches were found there, a new contact is created in enKod and the scenario is run with it.

Globally, identifiers are necessary to search for a contact or create a new one:

• if it is a new contact - all passed identifiers are created for it;
• if at least one of the passed identifiers is found in the database - the scenario for this existing contact is launched, but other passed identifiers are not written to it.

Contact does not exist (and is not deleted)

• only e-mail is passed; it does not exist in the database - a contact with e-mail is created, the scenario is run with this contact;
• only a phone number is passed; it is not in the database - a contact with a phone number is created, the scenario is run with this contact;
• both e-mail and phone number are passed; both identifiers are not in the database - a contact with e-mail and phone number is created, the scenario is run with this contact.

Contact in the list of deleted contacts

If a deleted contact is passed - it is restored and the scenario with it is run. Contact recovery rules:

• only e-mail is passed, it is in the deleted - the contact will be restored, the scenario will be run with this contact;
• only phone number was passed, it is in the deleted contacts - the contact will be restored, the scenario will be run with this contact;
• email and phone number are passed:
  • e-mail is in the deleted, phone does not exist in the base or in the deleted - the contact with e-mail will be restored, the phone will not be added to it. The contact scenario will be run;
  • phone is in deleted, e-mail does not exist - contact with the phone will be restored, e-mail will not be added to it. The contact scenario will be run;
  • both identifiers exist in the deleted contacts - the contact with e-mail will be restored, the scenario will be launched with this contact. The contact with phone will not be restored, the phone will remain with the deleted contact and will not be added to the contact with e-mail.

At least one contact identifier is in the database or in the list of deleted contacts

• A contact with e-mail and phone number was passed, contact A has e-mail in the database, and contact B has phone number in the deleted list - runs the scenario for contact A (with e-mail), contact with phone number will not be restored.
• A contact with e-mail and phone was passed, but contact A has the phone in the database and contact B has the e-mail in the deleted ones - runs the scenario for contact A (with phone), contact with e-mail is not restored.