Creating a Custom Preference Center in Power Pages

Peter Krause

Like ( 0 )

Report

Introduction

Managing consent for your customers is a vital part in every organization that wants to send out Marketing communication. Customer Insights – Journeys has a very granular consent management approach that greatly expands to possibilities of outbound marketing.
It is very important that consent for your customers is stored and managed directly in CI-J. The reason why is because there is a built-in functionality within the messaging engine that checks if a message can be sent out by taking the different settings into account as described in this article.
A very common scenario is that you may have a running web shop or a personalized customer space where your customers can login and manage their orders, tickets and so on. Typically, this would also be the place where consent to different topics or newsletters can be managed. So, how can you provide the management of consent for a customer in this scenario?

How the preference center works

The way how customers can manage their consent is through the out-of-the-box preference centers which are part of a compliance profile within CI-J. The preference center is an independent web page hosted on Azure that requires context to identify the entity and prefill the consent form accordingly. No login or additional information is needed, as the context information provided via the email link contains all the necessary details to identify the contact and prefill the fields in the preference center. The page can be designed just like any other form in Customer Insights – Journeys so that purposes and topics are displayed the way you want. However, the form is only able to display the preferences for one contact point at a time as you can see in the following picture.

Let’s look at some alternative options to create our own preference center. But before we dive into that, we need to understand how consent is stored within Dataverse.

Consent management data model

The following diagram depicts the most important tables and attributes. Please note that there is no relation to a contact or lead table. The concept is purely based on the contact point (email, phone number, custom).

The “contact point consent” (CPC) table contains and stores the consent records which are also listed in the consent center in the application. It has the following attributes (excerpt):

Channel: choice field with “Email” (534120000), “Text Message” (534120001) or “Custom” (534120002)
Consent Status: “opted in” (534120001), “opted-out” (534120002) or “not set” (534120000)
Consent Type: choice field with “Purpose” (53412000) and “Topic” (534120001)
Contact Point: Email address or phone number for which this record defines the consent.
Contact point consent: unique and primary id of the record.
Purpose: id of the corresponding purpose record.
Topic: id of the corresponding topic record
Reason: choice field that allows to provide an entry for the change of the record: “no reason” (534119999), “Opt-in – Advertisement” (534120000), “Opt-in – Landing page” (534120001), “Opt-in – Events” (534120002), “Opt-out – Content was irrelevant” (534120003), “Opt-out – Received too frequently” (534120004), “Opt-out – Didn’t recall signing up” (534120005), “Opt-out – Privacy concerns” (534120006), “Opt-out – One-click unsubscribe” (534120007)
Reason Description: additional free text field for the reason

Here is an example how the response to a specific consent request could look like:

A contact point consent record can be assigned to a specific topic and purpose or to just a purpose (with a topic of null).
With this information, it is possible to run queries against Dataverse to extract the right information. Let’s look at a scenario where you could make use of this to build your own preference center.

Using consent in external systems

A very typical use case is that you have CI-J running but also a public facing CMS or a web shop where your customers can log in and buy your products. In such a scenario, it would also be required to provide a page that allows your customers to manage their consent directly in the system. Because CI-J is still the system that sends out all marketing information and transactional messages, it is important that the internal consent engine can be used and that the consent settings are managed within CI-J. Here is where a custom preference center is required. A crucial prerequisite however is that you can uniquely identify the web shop user in Dataverse / CI-J as a contact. This could be achieved by synchronizing the contact identifier in CI-J to the user table in the web shop system or vice versa. In this example later, we will leverage the login mechanism for Dynamics 365 Power Pages to identify a contact in the system. To create the custom preference center, three steps are required:

Query prefill information
Design and build the custom preference center page
Update CI-J with captured information

Let’s take a closer look on how to accomplish these tasks.

Query prefill information

Because the expectation for a customer would be to see a prefilled consent page, this information must be extracted from Dataverse with this sequence of steps:

Take the contact identifier from CI-J or another unique identifier and query the contact table to extract the relevant channel information. In Dataverse, this would be “emailaddress1” and “mobilephone”.
Conduct another query against the table “msdynmkt_contactpointconsent4” and filter the records by the compliance profile that we want to display the consent options for. As a response, you would get all consent records for this contact in this compliance profile. This would include opt-ins and opt-outs.
Because the customer may not have given consent to all the topics, the number of consent records can be lower than the number of topics. Therefore, create another query to get all the topics from the commercial purpose within that compliance profile. That would allow the customer also to opt-in to additional topics.

Design and build the preference center

As a next step, you might want to design your custom preference page. There are basically no limits or constraints in how this page could look like. The next picture shows a very basic example of such a page.

The key point here is that the customer sees all consent in one page without the need to switch between channels. Be also aware of that there might be an intrinsic logic on the page. CI-J will not send a message for the topic of “hot coffee” if the purpose for the specific channel does not have an opt-in. This context should be reflected in the form when a customer clicks on those checkboxes.

Update consent in CI-J

When the form is properly set up, it is very easy to update the consent information in CI-J. There might be records which can be updated (for those which already exist) and some which might be created. For the records to be updated, the unique identifier for the contact point consent record id should be included. If there is no such identifier, a new consent record must be created.

Implementation example

There is a wide range of technologies that can be used to create such an implementation. Whether it is a web shop or just another content management system that allows your customers to login and consume personalized content, the consent management should be available right in there.
For this example, we chose Power Pages as the CMS. Power Pages also allow customers to log in, create tickets or start other processes. In Power Pages, it is possible to define the tables which can be used by the portal API, but for this example, we have not used the built-in options of Power Pages to give the solution a general character.
Instead, we used Azure API Management to encapsulate access to Dataverse and simplify access from the CMS. I assume the following conditions:

There is a contact sync between Dataverse and the external system. When a contact logs into the CMS, this contact is also known in Dataverse.
Access to the custom preference center is only possible when a user has logged in.
The custom preference center is specifically designed for one compliance center and a (commercial) purpose.

Access to Dataverse is accomplished by Azure Logic apps because those can easily be integrated with Azure APIM. Let’s take a look at the different APIs and the steps to use them. The resources to recreate this scenario are located in the corresponding Github folder.

The ultimate goal is to

Provide a menu item in the account menu on the top right for consent
retrieve all relevant consent information for just one compliance profile and a logged on contact
dynamically create a consent form that displays all consent options including checkboxes to change values
submit the new settings to they are reflected in CI-J.

In my example, the form looks like this.

As you can see, the form shows all commercial and tracking consent options for a given compliance profile including checkboxes to change the values. Please note that the checkboxes can display 3 values:

checked: is equals to “opt-in”
unchecked: is equals to “opt-out”
indeterminate: is equal to “not set”, e.g. there is no information about it

The contact can now make any changes and hit the “submit” button to send the new values back to CI-J.
Let’s look at the details how this can be achieved.

Retrieve consent information (prefill)

After the contact logged in and clicks on the “Consent” menu item, a custom page is used to implement Javascript functionality to reach out to Azure API Management and retrieve the consent information.
The process to retrieve contact consent information is displayed in the following picture.

With Azure APIM, you can design the APIs in the way that they are required. In my example, I created an API called “Consent Management” (base URL “manage-consent”). This is a HTTP GET request following a standard pattern. The goal of this API is to retrieve all contact point consent records (CPCs) for the given contact (identified by the contact id) as well as all purposes and topics for the given compliance profile (identified by the corresponding id).

The underlying Logic app retrieves those 2 parameters and

Retrieves the values for “emailaddress1” and “mobilephone” from this contact.
Takes these to values and retrieves all CPCs
Reads all purposes and topics from the compliance profile
Create a JSON document that combines all this information for the calling Javascript to consume.

The JSON response of the GET request is structured in the following way:

Here is an excerpt how this JSON document looks like:

This procedure ensures that we retrieve all the settings that a contact can make for the consent. This structure above makes it easy for a frontend technology to iterate through the document and show a corresponding form.

Creating the consent form

Dynamics 365 Power Pages come with a variety of possibilities to create pages, forms etc. In this case, a custom page is created that contains the required scripts to display the form. After the contact clicks on the “Consent” menu entry, an AJAX call is created that fires a GET request to the API. The contact id is already known at this point since the user has already logged in. The compliance profile is provided in the script. The script retrieves a JSON response like described in the previous section. Some scripting is required now to create the form.

The function above iterates through the different contact points, purposes and topics and creates the “purpose-topic” structure. Another interesting function is createCheckbox.
The goal with this setup is to finally collect the changes that a user has made on the form together with additional information to update or create contact point consent records. All this information is stored for each of the checkboxes which is handled by the createCheckbox function.

Depending on whether the checkbox is for a purpose or a topic, different values are provided. There are two properties to store the value: “checked” (current value) and “wasChecked” (original value) so a comparison take happen.
When the “Submit” button is clicked, another function iterates through the form, compares these two values and adds changes to an array which will be part of the POST request back to the system.

This function finally collects the changes and submits them through the POST request to CI-J like this:

Update contact consent

The overall process for consent update is simple:

For this process, another payload can be created and used to send to Azure APIM:

The logic app as the endpoint will just receive this payload and iterate through the CPCs. The unique identifier for a CPC is the “recordid”. When this is present, an existing CPC needs to be updated, otherwise a new one has to be created. The corresponding Logic App behind this looks like this:

Additional considerations

In this article, we explored the data model for consent management in CI-J and saw an implementation example for a custom preference center. While this example worked in a test environment, there are certainly additional aspects to consider for a productive usage.

Securing data access

Data retrieval and update from and to Dataverse has been implemented with Azure API Management and a corresponding subscription key. A production usage should make sure that this is a sufficient method and that the subscription key is stored in Azure Key Vault to be retrieved from the website. In addition, the recommendation for productive usage of Azure Logic apps should also be followed (such as service principals for connections to Dataverse).

Performance and Service limits

Depending on the website and its traffic, a substantial number of requests may be directed to Dataverse, which could impact service limits. For production use, it is crucial to make an appropriate estimation to ensure that calls to Dataverse are not throttled. Additionally, there are alternative methods to achieve the same functionality, some of which may offer better performance. It is essential to consider business requirements when selecting the most suitable approach.

Selective attributes for consent

In the example provided, the fields “emailaddress1” and “mobilephone” were utilized to display consent information. It is, however, also feasible to include additional fields for consent purposes. In such instances, these fields must be integrated into this scenario.

External consent management systems

Another use case requires the ability to change consent information externally. For instance, if you have an operational external consent management system, you may need to synchronize this information with CI-J. In such cases, a mapping must be created between the external system and CI-J.

Summary and conclusions

This article outlines a guide for creating a custom preference center within the Power Pages. It underscores the importance of managing customer consent directly in Customer Insights – Journeys (CI-J) to facilitate effective marketing communication. The advantages include:
Enhanced Customer Experience: A custom preference center enables customers to manage their consent with ease, thereby improving their overall experience.
Compliance and Accuracy: It ensures that consent is managed accurately and in accordance with regulations.
Integration and Efficiency: It seamlessly integrates with existing systems such as web shops, thereby enhancing the efficiency of consent management.