Query prefill information

1. 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”.
2. 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.
3. 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

Update consent in CI-J

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.