Microsoft MB-220: Consent Conflict After a List Purchase

Consent Conflict After a List Purchase

Contoso runs Customer Insights – Journeys for B2B marketing. The compliance team approved a purchased list of 12,000 contacts from a trade-show organizer. Each record carries a source value of TradeShow2024 and a consent flag of true recorded by the vendor, not by Contoso. Contoso's preference center uses two custom fields on the Contact entity: MarketingEmailOptIn (Yes/No) and OptInSource. The default consent model is configured as 'Restrictive' for the MarketingEmailOptIn field. A welcome journey is already live and triggers on contact creation. Within 24 hours of importing 4,000 of the 12,000 records, 3,900 contacts received the welcome email, and the legal team flagged the send. The import was done with the out-of-box import wizard, not the data management API.

1. Explain why the 3,900 contacts were eligible for the welcome journey despite the restrictive default, and what configuration change prevents recurrence.

Read the worked answer

The restrictive default applies only when a consent value is missing. The vendor list supplied MarketingEmailOptIn = Yes, so the restrictive default never engaged - the field was populated, and the journey's audience filter (or the absence of one) treated those contacts as opted in. The OptInSource value was TradeShow2024, which Contoso never validated; the platform does not judge provenance.

Two fixes, applied together:

Gate the journey on source, not just the flag. Add a condition to the welcome journey that requires OptInSource to be a Contoso-owned value (for example WebForm or InPersonSignup). Contacts imported with a vendor source fall out of the audience even when the flag is Yes.
Do not trust imported consent. For purchased lists, import with MarketingEmailOptIn blank so the restrictive default suppresses them, then run a re-consent journey that writes the flag and source only after a confirmed click.

The key judgement: a restrictive default is a safety net for absent data, not a filter on present data. Provenance must be enforced by an explicit audience condition.

2. The remaining 8,000 records are still queued. Describe the import approach you would use and how you would verify suppression before any journey can reach them.

Read the worked answer

Stop the wizard import and switch to a controlled path:

Import with MarketingEmailOptIn left blank and OptInSource = TradeShow2024, so the restrictive default marks every record as not consented at rest.
Run a segment of the imported cohort and export it for a spot-check against the vendor's consent evidence before any send.
Build a re-consent journey triggered on contact creation where OptInSource = TradeShow2024; the first step is a double opt-in email using a marketing email that does not require consent (a transactional/consent-request template), and only a confirmed click sets MarketingEmailOptIn = Yes and rewrites OptInSource = ContosoReConsent.
Verify with a test contact: create a record with the vendor source, confirm it appears in the re-consent journey and is excluded from the welcome journey, then confirm the flag flips only after the click.

This keeps the legal position defensible: no marketing email is sent on vendor-asserted consent, and every Yes in the system traces to a Contoso-observed action.