Skip to main content

Notifications

Throttling Email Messages with Dynamics 365 Customer Insights Journeys

Situation Definition    
 
Dynamics 365 Customer Insights Journeys (CIJ) provides customers the ability to communicate with individuals at a large scale. It does this in an efficient manner and can deliver high volume of emails in a small timeframe, sending communications as fast as possible. However, certain scenarios require the ability to communicate with a large audience but in a controlled manner, spread over a predefined period of time. For example, if an email communication is sent with the call to action being to reach a call center, organizations may want to ensure the call center does not receive more phone calls that it can handle thus would like to spread the outbound communications.
To throttle the sending of communications, it becomes necessary to identify the batches of contacts to be reached and pass these batches to the Journey Orchestration of CIJ. This article describes three possible approaches to do this.
For the purpose of this article, let's consider Contoso is launching a week-long campaign to reach out an identified subset of their customers that have expressed interest in the  new product. This expression of interest has been recorded in a lead and associated with a contact.

 
In the lead, we have added two columns to assist in the control of the email send:
  • Ready to Contact – This is a Yes/No field added with the default value of No
  • Batch Number – This is an integer field which will indicate in which batch will the lead be sent for a given campaign. 
In the following sections we describe different approaches to achieve the email throttling using these fields. Each approach will have its own pros and cons which should be considered for the specific scenario.

Approach 1 – Data driven segment additions
In the first approach, we will leverage the fact that CIJ Segments will be frequently evaluating to identify new members in Dynamics that belong to a given segment. To do this, we create our segment of contacts that have a lead that expressed an interest in the Airpot product. We are also adding a condition that leads must be marked as “Ready to Contact”. 

 
Since the default value of Ready to Contact is No, the segment will start empty.
We can then use the “Use this to create a journey button” and start the design of our campaign. We will use the frequency option of “a one-time journey where newly added audience members can start at any time” and then specify a start and end date. This duration should allow for the time that all the leads will be moving to a positive Ready to Contact.

 
In the journey we can then create the necessary communication path. For simplicity, the journey in this example is a simple email being sent to the contacts. 
 

Once the journey is set to live, we can start changing the value of Ready to Contact from No to Yes. As we do and the segment re-evaluates, the emails will be sent. This way we can control how many and when those emails are sent. 
 
Approach 1 Pros:
Don’t need to define segments ahead of time and can randomize the inclusion
Less CIJ configuration (single segment and single journey)
Approach 1 Cons:
Requires data worker to update the information at the necessary times  
If update done manually in Dynamics, can be time consuming
 
Approach 2 – In-journey branching of batches  
One additional approach to achieve the throttling is add logic into the journey. In this scenario, the starting point is a segment with all the contacts that have expressed interest in the Airpot product.

Note that we are adding no additional criteria in terms of using the “Ready to Contact” or “Batch Number” fields.

Next, we will create different segments for the various batches that each contact belongs to.

 
In this case, note that we are not adding the criteria that identifies the interest in Airpot as this will no longer be required.

In this example, we are using a batch number field to identify the groups of contacts to reach out to. Depending on business needs, other fields or criteria could be used.

We then create the journey, starting from our global segment with all the Airpot interests. In this case, we can select the frequency option of “A one-time journey with static audience” and the start date of the campaign.

 
Within the journey, rather than a simple email send, we will split the journey into each batch using the “Branch based on a specific value” tile in the journey editor. Selecting the newly added tile, we can specify the criteria. Since we are basing the split based on the previously created segments, we use the option “Make condition on segment membership” and choose a different segment, creating as many branches as batches.
 
 
Then, we introduce a delay for all branches except the one corresponding to batch 1. Through this delay the journey will pace the delivery of the emails. To do this, in each branch we add a tile “Hold an action for a specific time”. How long a given batch should be held will depend on the need. In our example, we are sending 2 batches, 1 day apart, so the configuration of the delay would look like this:
 
 
 
Then, in each branch we add a tile for the email send. The fully configured journey would look like this:
 
 
 
Approach 2 Pros
Totally automated execution once set-up
 
Approach 2 Cons
Requires multiple segments per campaign
More complex journey
Less control should the initial throttling rhythm needed to be adjusted

 
Anti Pattern – Convert to trigger based journey
One tempting option is to use triggers to reflect the update of when a batch is ready to send. An external system or bulk operation updates records in Dataverse are these updates are used to fire a trigger. This trigger is then used in the journey the send the emails. This allows the batching logic to be externalized to the segment or journey configuration which could be preferred depending on the source of the updates to trigger the next batch of emails. 

Although this approach can work at small scale, working with batches of over 700 records, the updates could be coming in higher throughput than allowed in the fair use policy (https://learn.microsoft.com/en-us/dynamics365/customer-insights/journeys/fair-use-policy#customer-insights---journeys-real-time-marketing)  and that could degrade the performance. Do note that the 700 trigger per minute limit in the fair use policy is per environment so having multiple journeys will not resolve the scale limitations of this approach. 
 

Comments