Customer Insights Journeys is a powerful tool for orchestrating personalized communications. A common challenge in these communications is when the when email content is determined by related entities that have one to many relationships with the contact, like a customer having multiple bank accounts or utilities accounts. Ensuring the right content reaches the right person at the right time requires thoughtful planning and execution. Let’s explore the challenge and delve into three potential solutions.User Scenario
To illustrate the challenge, consider the case of Contoso, a bank that offers services like current accounts, mortgages, and insurance to its customers. Contoso has modelled the services owned by each customer in a custom table within Dataverse named “Bank Account.” This table includes detailed information about each service, such as account type, balance, status, and recent activity. Contoso’s goal is to use this data to send targeted and personalized email communications to customers, ensuring that each email reflects specific account details relevant to the recipient. The communications may be a result of profiling the bank account information but could also come after data in the bank account changed after an overnight batch interface with Contoso banking back-end system such as statements are ready or a bill is ready to send.Contoso considered the use of trigger-based journeys based on the changes received from the back-end systems, but the volume of overnight data batch exceeded the fair use policy of Customer Insights - Journeys (Service limits and fair use policy - Dynamics 365 Customer Insights | Microsoft Learn).Without a robust strategy, Contoso risks sending generalized emails that fail to capture the nuances of individual customer profiles, not sending the emails if trigger volume thresholds are exceeded, or worse, sending incorrect account details that could undermine trust and credibility.Potential Solutions
There are several ways to solve this problem Customer Insights - Journeys. Each solution leverages different techniques to manage the data relationships and personalize your communications effectively and ensure a scalable solution where transactional volumes are within the safe use limits. To illustrate the possible solutions, we will use the scenario of customers with accounts that have been overdrawn needing to receive an overdraft notice. Each night, the bank has a batch of accounts which need to receive an overdraft notice.Here are three solution options.1. Segment on related entity and use list in personalization
The first solution involves creating a segment based on the related “bank account” to identify the contacts that should receive a communication because of their bank account attributes. For example, you might identify customers with accounts that have balances exceeding a certain threshold.
First, add the Bank Account table to the list of tables available for segmentation and then create a segment that identifies the contacts that have a bank account record with the status of “Overdrawn”.
Second, use the email personalization tools to create a list of the “bank accounts”. This allows the message to be specific to the right “bank accounts”, since the same contact could have multiple bank accounts. Within the personalization tokens in CIJ, it is possible to add filtering and sorting criteria so that only the appropriate “bank accounts” are added to the list. More details on the personalization of lists can be found in Personalize lists of content in emails - Dynamics 365 Customer Insights | Microsoft Learn.
That list will then be added to the body of the email, which will loop through the bank accounts matching the criteria and add them to the resulting email. So the design below:
Would result in an email sent to a customer with 2 overdrawn accounts that looks like this:
2. Generate personalized content in a supporting table
The second approach involves pre-generating personalized content in a supporting table. This table acts as a bridge, housing both the content and the specific criteria for when it should be sent. Here’s an outline of the process:- Create a supporting table which we can call “communication requests” which has a Many to One relationship to Contact. This includes a text field with the content to be sent and a date on which the content is to be sent.
- Create a batch process to populate the communication requests. Alternatively, the overnight batch process can be extended to also populate the communication requests.
- Create a segment to identify the contact that have communication request records scheduled to be sent today.
- Create a recurring journey based on the previously created segment.
- Create an email which will use the personalization features of the CIJ Emails to work with the list of communication requests, filtering to the current date.
This solution provides finer control on the message to be sent and allows for the process to be setup once and let it execute automatically on a daily basis. It also covers situations where the source data for the personalization is not stored in CIJ, sharing only the text that is desired to be sent to the customer. However, it does require more upfront planning and data preparation, as the supporting table must be filled with the right requests.3. Bank account as audience in lead table
An alternative approach would be to consider the “bank account” as the target audience and not the customer. In this approach, Contoso could replicate the bank account records into the lead table. Not all attributes would need to be replicated, only those determined by the business requirements as key ones for the communication preferences or segmentation. As Lead already has a relationship with the Contact table, this approach could leverage other personalization attributes and the customer level. With the bank account data replicated in the Lead, you can create segment of leads and use those in the journeys. The impact to be aware of is that moving to a different Audience, the number of profiles needed in the CIJ quota will increase to all the bank accounts not just the customers.To build this solution, it would be required to:- Customize the Lead table to include the necessary attributes for the replica of bank account data. Contoso has decided to keep the bank account details in the record but add a field to the lead table to identify the specific leads coming from the bank account records and a lookup field to relate the lead to the originating bank account.
- Create a replication mechanism appropriate to the volume of changes. For the purpose of this document, we are showing replica via Power Automate Flow. The flow will trigger when a new bank account is created.
It will retrieve the contact for the bank account.
And will create a new lead copying the contact’s first name, last name, email address and phone number and adding the bank account’s name as the topic of the lead. In this example we are adding sufficient attributes to be able to visually understand what the lead represents (first name, last name) but for other attributes that may be needed in email personalization or journey branching Contoso would be navigating the relationship to the Contact. This minimizes data replication and the data that would need to be kept in synch should it change.
What will be required to have in the lead is the contact point data: email address for email communication and/or phone number for SMS contacts.
- Create a lead segment for the identification of target bank accounts. The segment adds a filter based on the lead type to only consider leads that copies of the bank account and also filters on the bank account’s status to find the overdrawn accounts.
- Finally, the personalization elements added from the Lead table into the email. We are able to add, as an example, the contact’s first name. Note that, since the target audience of the email will be a lead, we are navigating the relationship to the parent contact.
Because one lead can only be related to one bank account, it is not necessary to use lists in the personalization when leveraging bank account data but can add fields from the bank account record directly. So an email like the below
Would result in this email being received for each bank account the customer has in overdrawn state.
This approach can streamline the personalization process and reduce complexity in the email authoring. It will also allow for separate emails to be sent per bank account to the same customer and maintain different contact points (i.e. email address) for each bank account. However, it does need a level of data redundancy, it requires regular updates to ensure the mirrored information remains up to date and it should account for the increase in interacted people on the CIJ quota.
Conclusion
In conclusion, this document highlights a strategic approach to handling the bank account scenario by leveraging segments rather than solely relying on triggers to drive actions. Working with segments offers a higher scale which is needed in batch communications. Combining that with the personalization options within Customer Insights Journeys there are several approaches to create a solution, depending on the specific business requirements.
