Using Variables from Order in Workflow

Let's look at using variables from an order event in a transactional workflow, for example, Order delivered. Correctly writing variables is necessary for the workflow to work without errors and for all the required parameters to be inserted into the message content.

Main Steps for Preparing Transactional Campaigns

Preparing any workflow that sends messages with information about user data, delivery address, order number, etc., includes the following steps:

  • transferring of order data via API (you can use Add orders or Generate event API resources);
  • preparing an email with dynamic content;
  • setting up a workflow for sending the email.

We will look at transferring orders using the Add orders API resource. You can find out more about its use in this manual.

Transferring Order Data

The request contains one or more orders with mandatory and optional fields.

Required fields for the orders array:

  • ExternalOrderId,
  • ExternalCustomerId,
  • TotalCost,
  • Status,
  • Date,
  • Email or Phone

Required fields for the items array:

  • ExternalItemId,
  • Name,
  • Quantity,
  • Cost,
  • Url,
  • ImageUrl

Also, several important order statuses display the sales funnel:

  • A created order usually has the INITIALIZED status.
  • An order in the delivery process is displayed with the IN_PROGRESS status.
  • For paid and delivered orders, the DELIVERED status is used.
  • For canceled – CANCELLED.

Such a differentiation is necessary primarily to understand precisely what stage the customer is at, and not send delivery messages to those who canceled or just created the order.

Creating Events

Every time you pass order data via the API, corresponding events are created in the system, which you can later use as a condition that launches a triggered workflow.

Launch conditions

The names of transactional events consist of the word order and the status added to it, for example, orderDELIVERED. You can see them in the TriggersEvent history section in the eSputnik system.

Event history

Each event has a unique key. For order events, these are order identifiers, which are passed in the externalOrderId parameter.

📘

Note

The extrenalCustomerId and ContactId parameters are matched when the order is first submitted. Accordingly, in subsequent orders, even if you specify the email of a new contact in the body of the order, but the extrenalCustomerId will belong to a contact that is already in the system, the order will be assigned to the contact with whom the initial matching took place.

For example, order events include the following standard variables:

  • ${eventKey} – order unique key, contains the externalOrderId field value.
  • ${orderId} – order ID in the eSputnik database. The parameter is needed for the workflow’s functioning.
  • ${contactId} – contact ID in eSputnik.
  • ${emailAddress} – customer’s email address (if provided in the order).
  • ${SMS} – customer’s phone number (if provided in the order).
Event parameters

Using Event Parameters in Workflow

Write event parameters in workflows precisely in the form they are transmitted in events. If the standard email parameter is passed in an order event, the variable in the Email input field in the workflow should also be called ${emailAddress}. Other formats like ${Email} will not work in the workflow.

Email block parameters

For users' convenience, system events (generated by a subscribe request or a regular workflow) have some standard parameters, so such workflow blocks usually work by default, even without manually specifying variables. However, if you change the event for launching the workflow to something other than the standard one, the workflow will not run by default. The eSputnik team recommends manually specifying variables in the workflow to avoid errors.