Keeping Your Subscription Lists Up To Date In D365 Marketing

If you’re a good marketer, you give your subscribers options. You allow people to sign up to get content about Events or new Products or Services you offer. Ideally they want to get all of your content, but letting them pick and choose might mean you still have the ability to send someone marketing emails about one or two topics rather than them unsubscribing altogether. In D365 Marketing you can create your own custom subscription page, and use it for both Outbound and Real-time Marketing. This is great, but what about when someone opts out of everything, or a user changes things and opts a Contact out of getting marketing emails. Have you ever considered how they then get taken out of your subscription lists? If not, this is one for you.

Contact Information

First things first, understand what is used when sending out content using either Outbound (OBM) or Real-time Journeys. The Do Not Bulk Email field (donotbulkemail) is the key field used to determine if a Contact will be sent emails while on a Journey. However, with Real-time Marketing (RTM) you have the Consent center with records by email address to determine if it’s Opted In or Opted Out of marketing communication and tracking.

• If there is no Consent record, and the Bulk Email field is set to Allow, emails can (currently) go out via both OBM and RTM.
• If the Bulk Email field is set to Do Not Allow, Contacts will not get emails from either OBM or RTM.
• If the Consent record is Opted Out and the Bulk Email field is set to Allow, Contacts can get emails from OBM
• If the Consent record is Opted In and the Bulk Email is set to Do Not Allow, Contacts cannot get emails from either OBM or RTM

So you can see, the Bulk Email field rules it all really.

Now that you understand what controls the types of emails that can be sent to a Contact (OBM or RTM), what about if someone unsubscribes but they are currently in one or more of your Subscription Lists? The answer is nothing, absolutely nothing. They will still be in there. This means, if someone creates an Outbound Journey with the ability to send the Journey to everyone that is in a Subscription List, those Contacts will start the Journey. They won’t get any of the emails because their Bulk Email field is Do Not Allow, but you will have an over inflated number of those going through the Journey. Likewise, if you do any reporting of how impressive the numbers of people in your various subscription lists is, you will be reporting incorrect numbers. We can fix this though, by creating one of two different flows in Power Automate.

Flow For Outbound Marketing

If you are only doing OBM or are doing a mixture of OBM and RTM, but are using an outbound subscription centre (which is definitely always my choice of approaches), this is the flow for you. We will start off with a simple flow that triggers when the donotbulkemail field is changed and the field equals true, which means it’s been changed to Do Not Allow. All actions are from the Dataverse connector. We can run it on the Contact table, and only when the record is modified. Reason for this being you can’t add a Subscription List to a record that hasn’t been created yet, so no point in running it on the Add change type.

Our next step is a List rows action to find any related subscription lists that the Contact is a member of. This is actually the Marketing Lists table. Using a Fetch XML query, we can find all marketing lists where the Contact that triggered the flow is a member of. We include a filter that only pulls back lists that have a flag indicating it’s a subscription list so we don’t remove them from any other marketing lists people may have added them to.

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true">
  <entity name="list">
    <attribute name="listname" />
    <attribute name="listid" />
    <order attribute="listname" descending="true" />
    <filter type="and">
      <condition attribute="msdyncrm_issubscription" operator="eq" value="1" />
    </filter>
    <link-entity name="listmember" from="listid" to="listid" visible="false" intersect="true">
      <link-entity name="contact" from="contactid" to="entityid" alias="ae">
        <filter type="and">
          <condition attribute="contactid" operator="eq" value="@{triggerOutputs()?['body/contactid']}" />
        </filter>
      </link-entity>
    </link-entity>
  </entity>
</fetch>

The last part of the flow is an Apply to each that will run on each list returned in the step above. This is the Perform a bound action step and should have the Marketing Lists table selected, and the Action Name of Remove Member List. Find the Marketing List value from your list rows step and add that as the Row ID. Then add the Contact value from the trigger and add that to the Entity ID field. I think something may have been updated recently, because it used to have a space just for the EntityID. Now it seems to show all fields for the Marketing List, so go with the one that says listmember listmemberid.

Now go and change the Bulk Email field on a Contact that has already been added to some of your Subscription Lists and wait for the flow to run. The Contact will no longer be a part of those lists now and your Subscription Lists Member count will be accurate.

Flow For Real-time Marketing

Don’t create both flows (or you will end up in a loop between the two), but if you are using Real-time Marketing AND using the Consent Centre page rather than a pretty outbound subscription centre, you will want to take this approach. The idea with this one is we want to always make sure that Bulk Email field is kept up to date and in line with the Consent record for the matching email address on the Contact. Again, it’s the Dataverse connector, and this flow will trigger on the Contact Point Consents table. Make sure you pick the second table that shows in the list, as for some silly reason it’s in there 4 times. You can run this when the record is Added or Modified.

Now we will have a condition that will check to see if someone Opted Out rather than back in via the Consent record. So the three fields conditions to add are as follows:

• Consent Status is equal to 534120002 (Opted Out)
• Consent Type is equal to 534120000 (Marketing Communication)
• Type is equal to 534120000 (Email)

If all of those conditions are met, we go down the Yes branch. To keep this in line with all Contacts who have this email address on their record, a List rows step is used to search for any Contact who has the same email address on their record that is linked to the Contact Point Consent record. You can use this Fetch XML Query below.

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="contact">
    <attribute name="emailaddress1" />
    <attribute name="contactid" />
    <order attribute="fullname" descending="false" />
    <filter type="and">
      <condition attribute="emailaddress1" operator="eq" value="@{triggerOutputs()?['body/msdynmkt_contactpointvalue']}" />
    </filter>
  </entity>
</fetch>

Now we add in an Apply to each step to update each Contact that was returned. Keep in mind that you could have duplicates and people could also share an email address. Our next action is an Update row step where we update the Contact using the ID of the records returned, and change the Bulk Email field to Yes, which will be what we know as Do Not Allow. This means that not only will the Contact not get RTM emails, but they also now won’t get OBM emails. This makes sense as your Contacts won’t have any concept of OBM and RTM, they only know that they have opted out and don’t want any more marketing emails from you.

Now we are just repeating the steps that were used in flow number 1 and finding all of the Marketing Lists that each Contact is a member of and use the same Fetch XML in a List rows step. The only difference will be the reference to where the Contact ID is coming from. Notice that in the query below, the value comes from the step I named ‘For Each Contact Make Opt Out Changes’. After the step where we find all the subscription lists, add in an Apply to each step, and for each list found, we have a Perform a bound action to remove the member from the list.

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true">
  <entity name="list">
    <attribute name="listname" />
    <attribute name="listid" />
    <order attribute="listname" descending="true" />
    <filter type="and">
      <condition attribute="msdyncrm_issubscription" operator="eq" value="1" />
    </filter>
    <link-entity name="listmember" from="listid" to="listid" visible="false" intersect="true">
      <link-entity name="contact" from="contactid" to="entityid" alias="ae">
        <filter type="and">
          <condition attribute="contactid" operator="eq" value="@{items('For_Each_Contact_Make_Opt_Out_Changes')?['contactid']}" />
        </filter>
      </link-entity>
    </link-entity>
  </entity>
</fetch>

Going back up to the second step of the flow where we added the condition, we can add some logic to the No branch. I’ve got another condition to check and make sure the Consent record that was changed is because someone Opted In. There is only one change and that’s in the id used for the Consent Status.

• Consent Status is equal to 534120001 (Opted In)
• Consent Type is equal to 534120000 (Marketing Communication)
• Type is equal to 534120000 (Email)

If the Contact was opted back in, we want to make sure (just in case) that the Bulk Email field is also set to Allow. Without that change, if it’s still set to Do Not Allow, no emails will go out. So we follow down the Yes branch and do the exact same this as before with the Fetch XML query to find Contacts with the same email address. Then an Apply to each is used to Update a row and change the Bulk Email field to No, which makes it set to Allow.

You don’t HAVE to have this type of process in place but it definitely helps to make sure you aren’t looking at incorrect numbers for your Subscription List Member counts, and aren’t starting Contacts down a Journey when they might not ever be sent an email. Having something like this in place when someone opts out is a great way to keep your Subscription Lists clean, and make sure the OBM and RTM mechanisms for allowing emails to go out are in sync.