What happens to the consent when an email is changed in Customer Insights?

Recently, I came across an interesting topic in a forum discussion—Consent Management in Customer Insights, specifically regarding email change and the associated consent. This question seems to pop up frequently, so it’s clearly relevant to many. In Outbound Marketing, consent was directly tied to the contact’s email field or through subscription lists. Changing an email address wasn’t a big issue in that setup. However, with Realtime Marketing, where consent is linked to contact points, a change in email address—due to a job switch or domain change, for instance—can cause the consent to be lost.

Quick Disclaimer: Since consent management also involves legal considerations, the ideas and suggestions I provide here are my personal recommendations. Please consult with your legal department to ensure compliance with relevant laws.

The main question here is: What happens to the consent or unsubscribe status when an email address changes? Does the consent stay valid, or should you ask for consent again for the new email?

Below are a two options for managing this situation.

Option 1: Request Consent Again

One approach is to request consent again every time a contact’s email address is updated. In this method, an email is sent to the contact whenever their email address changes, asking them to give consent again. This is the simpler solution, and the trigger for this action already exists: Contact email address is updated.

Before creating the journey, let’s design the email. You have two options:

  1. Button leading to a landing page: The page displays a thank-you message, and after clicking, a Power Automate flow triggers to create the new contact point consent.
  2. Button leading to the preference center: Here, the contact can update their preferences, and the consent is automatically created.

I opted for the second option.

Email with consent

If you use a restrictive enforcement model for the “Commercial” purpose, the email must be transactional.

Create a journey that looks like this:

Journey for request of consent after email changes

This option is quick to implement, and the trigger already exists. The new consent record is created automatically and is easy to track later. However, the consent associated with the old email remains in the system, raising questions about whether it should be retained or deleted. Additionally, requiring the contact to provide consent again creates a barrier, increasing the risk of losing them.

Option 2: Transfer Consent to a New Record

The second option involves transferring the value of the existing consent record from the old email address to the new one. This approach proved to be more complex than I initially expected. A Power Automate flow that reacts to email address changes and updates existing consent records with the new email address is not permitted, as the email address in a consent record cannot be changed.

To proceed, you’ll need to identify whether the old email address had an opt-in or opt-out status, as this will need to be transferred to the new address. However, retrieving the old value becomes challenging once the new email is saved.

Part 1: Using Audit History in Power Automate

				
					_objectid_value eq '@{triggerOutputs()?['body/contactid']}'
				
			

Initially, I considered storing the old email address in a separate field using a synchronous workflow. However, extracting the old value from the audit history seemed more elegant, though it does add complexity.

Let’s start with the Power Automate, which should only trigger when the email address changes and only if the email address is not empty. Otherwise it makes no sense. I then load the audit history for the contact object type.

Note: The audit history must of course be activated for the contact beforehand. And yes, I did forget this first myself..

Power Automate step 1

Next, I add a delay action for 2 minutes, because I have realised that the audit history is not always available immediately after saving the contact.

Then I use the Compose function to be able to process the audit history better. You can find the json for this here:

				
					json(outputs('List_rows_-_Audits_of_contact')?['body/value'][0]['changedata'])['changedAttributes']
				
			

Of course, it is also possible that someone in the contact not only changes the email, but also other fields at the same time. In this case, the Compose function returns an array with several blocks. This then looks something like this:

				
					[
  {
    "logicalName": "emailaddress1",
    "oldValue": "amanda@bestforyouorganicscompany.com",
    "newValue": "amanda.hegg@bestforyouorganicscompany.com"
  },
  {
    "logicalName": "telephone1",
    "oldValue": null,
    "newValue": "+4912345678"
  },
  {
    "logicalName": "jobtitle",
    "oldValue": null,
    "newValue": "Consultant"
  }
]
				
			

From this, we only need the old value of the email field. I therefore use the filter and then the select action. The filter action only extracts the part of the array that contains the emailaddress1 values.

Power Automate step 3

In the extended mode of the filter action, the expression should look like this:

				
					equals(item()?['logicalName'], 'emailaddress1')
				
			

The select function then retrieves the value of the old email from the filter array. In the Select step, it is best to click on the small Switch Map to text mode icon to the right of the map fields and enter the following so that only the email address is returned:

				
					item()['oldValue']
				
			
Power Automate Schritt 4

I have now extracted the old email value from the audit history. It is still in an array, but with the join function, I can convert it into a text.

				
					join(body('Select'),';')
				
			

Part 2: Find and use the consent of the old email

Now that we have the old email address, I use it to find existing Contact Point consents. I want to transfer the Opt In or Opt Out value from the old consent to the new consent record for the new email address.

First I need the GUID of the purpose (msdynmkt_purpose) and have to find the topics (msdynmkt_topic) to which the contact may have subscribed or unsubscribed.

Then I search for the existing Contact Point Consents for the old email address using the List Row action.

Power Automate 6
				
					msdynmkt_contactpointvalue eq '@{variables('oldValueEmailaddress')}' and _msdynmkt_purposeid_value eq '@{variables('CommercialGUID')}' and msdynmkt_contactpointtype eq 534120000 and msdynmkt_contactpointconsenttype eq 534120000
				
			

The msdynmkt_contactpointconsenttype field specifies whether it is a data record for purposes or topics. 534120000 stands for purpose and 534120001 stands for topic. And the field msdynmkt_contactpointtype with the value 534120000 defines that the channel is email.

In the subsequent condition, we check whether values are returned from the list function. I use the empty expression for this. If no records are found, the value true is returned and we can stop the flow, no data needs to be transferred. If records from the old email are found, the expression returns false and we also create new contact point consents for the new email address.

				
					empty(outputs('List_rows_-_Find_existing_CPCs_for_Purpose')?['body/value'])
				
			

In the next action, I create the new data record as follows:

  • Channel: Email
  • Consent status: Use the dynamic value from the list rows function of the existing contact point consent
  • Contact point: Use the new email address from the trigger
  • Reason: A reason of your choice, I chose No Reason
  • Source: A source of your choice, I chose Loaded
  • Consent type: Purpose
  • Reason description: Add a description,
  • Purpose: Add the GUID of the purpose from the variable we defined earlier.

I then repeat everything for the topics. In principle, I use the same filter as before for the listing, except that this time I enter the 534120001 for msdynmkt_contactpointconsenttype.

				
					msdynmkt_contactpointvalue eq '@{variables('oldValueEmailaddress')}' and _msdynmkt_purposeid_value eq '@{variables('CommercialGUID')}' and msdynmkt_contactpointtype eq 534120000 and msdynmkt_contactpointconsenttype eq 534120001
				
			

And here, too, the condition appears again, which either ends the flow or creates a new data record for the new email address.

  • Channel: Email
  • Consent status: Use the dynamic value from the list rows function of the existing contact point consent
  • Contact point: Use the new email address from the trigger
  • Reason: A reason of your choice, I chose No Reason
  • Source: A source of your choice, I chose Loaded
  • Consent type: Topic
  • Reason description: Add a description,
  • Purpose: Add the GUID of the purpose from the variable we defined earlier.
  • Topic: GUID from the list row function ealier

And that’s it.

The Power Automate starts when an email address is changed, searches for the old email address via the monitoring history and, if there was already a Consent record, also creates a new record for the email address.

Note 1: The prerequisite for this flow is that there is only one compliance profile. It is not designed for multiple business units.

Note 2: Please also consider error handling in your flow. Then you will be informed in case something goes wrong. There is many great content from the community out there about this topic.

Summary

This article deals with the question of what happens to consent when a contact’s email address changes. Either the consent is requested again (option 1), or the existing consent is transferred to the new email address (option 2). Both approaches have their advantages and disadvantages. I tend to ask the contact explicitly for the new consent, as customers are use to resubscribe to newsletters if their email address changes. However, option 2 can be useful, especially in the B2B sector. Ultimately, the decision is up to you: How would you handle it?

2 Responses

  1. Great post! To me it is a little bit puzzling that there is no relationship between the contact and the “contact point consent” record. That would have made this scenario much easier to handle…

Leave a Reply

Your email address will not be published. Required fields are marked *

WordPress Cookie Notice by Real Cookie Banner