Almanac
Microsoft/d365ci-journeysDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Insights – Journeys (formerly Marketing): implementation notes, gotchas, and configuration decisions beyond the official docs — across real-time journeys, segments, email and SMS marketing, event management, lead scoring, Copilot, analytics, and administration.

d365ci-journeys/10-decision-guides/feature-consent-and-compliance-profile-strategy.md
feature-consent-and-compliance-profile-strategy.mdv1 · history
CurrentApplies to Real-time journeysUpdated 6 days agoSource Microsoft Learn ↗

What it does

Real-time journeys stores consent as a three-level structure — compliance profile, then purpose, then topic — recorded against a contact point such as an email address or mobile number rather than against a contact record. You design that structure once, and it is close to permanent, because nothing in it can be deleted.

This doc is about how to shape it. It is not legal advice, and you should not give any. Model what the client's privacy counsel tells you to model.

Key facts

  • The hierarchy is compliance profile → purpose → topic. A profile holds many purposes; a purpose can be shared across profiles; a topic belongs to exactly one purpose.
  • Profiles come in two types: Preference Center, where Journeys hosts the consent page, and External Link, where the unsubscribe link hands off to the client's own system. Configured under Settings > Customer engagement > Compliance profiles.
  • Three purpose types are created by default with a new profile: Commercial communication, Transactional communication and Tracking. All are editable, and you can add your own.
  • Enforcement is set on the purpose, not the profile, and there are three modes. Restrictive sends only to contact points with an opt-in record. Non-restrictive sends unless there is an explicit opt-out. Disabled skips the consent check entirely.
  • Changing enforcement on a shared purpose changes it everywhere that purpose is used. Separate purposes per brand or region are the supported way to run different strictness.
  • Each compliance profile has exactly one tracking purpose. The only way to share a tracking purpose between profiles is the Use previously captured consent option, chosen at profile creation.
  • Delivery needs consent at both levels: the parent purpose and, if a topic is set, the topic. Opting into a topic while opted out of its purpose sends nothing.
  • Compliance profiles, purposes and topics cannot be deleted. The only cleanup is setting them Inactive, which hides them from experiences but leaves existing journeys using them.
  • Real-time journeys does not evaluate DoNotEmail, DoNotBulkEmail or DoNotTrack by default. Turn on the Check contact consent in real-time journeys feature switch under Settings > Overview > Feature switches to make it do so, and it then applies to contacts only — not leads, not Customer Insights – Data profiles, and not text or custom channels.
  • Preference centres never write back to DoNotEmail, DoNotBulkEmail or DoNotTrack. If the client's service desk relies on those flags, they will drift.

When to use / skip

For a UK or EU client my default is: one compliance profile per brand that a recipient would recognise as a distinct sender, restrictive enforcement on the commercial purpose, non-restrictive on the transactional purpose, and a small, deliberate set of topics under commercial. That is usually two to five topics — newsletter, product news, events, offers — not one per campaign.

Resist the urge to model every consent nuance in the hierarchy. Topics multiply fast, they cannot be deleted, and a preference centre with fourteen checkboxes produces worse consent outcomes than one with four. Where the client's legal position needs something finer, put it in the segment logic rather than the consent tree.

The place to be careful is transactional. Non-restrictive enforcement on a transactional purpose is normal and defensible for genuine service messages, and it is also the door through which marketing content escapes. The control is process — who can select that purpose on a message — not configuration. Say so explicitly to the client and get the approval route agreed.

Skip multiple compliance profiles if the client has one brand and one legal entity. A single profile with well-chosen purposes handles most UK mid-market cleanly, and a profile per market that you cannot delete later is a decision you will regret.

Two things I would push a client to decide with their own lawyers rather than accepting a default: whether tracking consent needs to be separately captured for their audience, and whether existing outbound opt-ins carry over as valid consent under their interpretation. Both are legal calls. Your job is to model whatever they answer.

Configuration decisions

  • Number of compliance profiles, and on what basis — brand, legal entity, market, business unit. Profiles cannot be deleted, so this is a one-way door.
  • Whether to share a tracking purpose across profiles. Use previously captured consent is only available at profile creation, and there is no supported way to unlink a tracking purpose afterwards.
  • Enforcement mode per purpose, and whether any purpose needs to be split so two brands can run different strictness.
  • Preference centre hosted in Journeys, or external link to the client's own consent system. External means you own token handling and the six-month link expiry.
  • The topic list, agreed with marketing and signed off by whoever owns privacy.

Gotchas

  • Nothing can be deleted. A test compliance profile created during a demo is in that environment permanently, and it appears in pick lists forever unless deactivated.
  • Enforcement changes on a shared purpose propagate silently to every profile using it. A tweak for one market changes another.
  • Preference centres never write back to the legacy do-not flags, so the two views of consent drift apart. Pick which one the business treats as truth.
  • Turning on the contact-consent feature switch after go-live can suppress sends overnight for anyone whose DoNotBulkEmail was set years ago by an import nobody remembers.

Consultant notes

  • Say plainly and in writing that you are configuring what their legal advisers specify, and that you are not advising on lawfulness of processing. Put the topic and purpose list in front of counsel before you build it.
  • Demo the preference centre early. Clients form strong opinions about it, and those opinions change the topic model — better to hear them before the topics are undeletable.
  • Push back on per-campaign topics. Offer to solve granularity with segments instead.
  • Test consent behaviour with a shared email address and a lead as well as a contact. The gaps in the feature switch's coverage are easiest to explain by showing them.
  • Before go-live, export consent records to Excel and keep the file. Environment restores revert consent to the backup state, and that export is the only reference you will have.

Worth another look if Microsoft extends the consent feature switch beyond contacts and email, or changes the unsubscribe link expiry.

Was this accurate?
Related
Compliance profiles, purposes and consent08-administrationAudience source: contacts, leads and profiles02-segments-and-audiencesRunning segments off Dataverse or off Customer Insights – Data10-decision-guidesSegmenting on Customer Insights – Data profiles02-segments-and-audiencesDynamics 365 Customer Insights – Journeys KB — Features & Changelog_rootTransactional and service messaging: Journeys or Power Automate10-decision-guides