Configure Dynamics 365 Customer Insights – Journeys
Core configuration concepts
Start with the environment-level setup that governs everything downstream: feature switches, default settings, and the connection between the marketing app and the rest of Dynamics 365. Candidates should know the roles of settings pages (default sender domain, consent configuration, data retention), business units and how they scope records, and the templates and content blocks library used later in emails and pages.
Understand how authentication and domains work. A marketing email domain must be authenticated (via DNS records) before it can send; unauthenticated domains are blocked or restricted. Similarly, form hosting and event portals rely on configured domains. Know the difference between the outbound marketing-style custom channels and standard email; also know where suppression lists and subscription centers are enabled.
Traps to watch for
- Questions that imply you can change the sender domain per email - the domain must be authenticated at the environment level first.
- Confusing security roles (who can access the app) with consent/opt-in settings (who can be contacted). These are separate controls.
- Assuming settings apply across environments - configuration is environment-specific.
- Mixing data retention defaults with consent expiry; they are distinct.
Rule of thumb
Before any journey can run, verify three things: the email domain is authenticated, the consent model is set (single vs. double opt-in), and the relevant security roles are assigned. If a question describes sending failing despite correct content, suspect domain authentication or consent configuration.
Worked example
A team reports that test sends work but production sends to external recipients fail. The likely cause is that the sending domain is not fully authenticated (missing DKIM/SPF records) or the recipients fall on a suppression list. The fix is configuration at the environment level, not editing the email.