CRED × Microsoft Dynamics 365 — sync, enrichment, troubleshooting

Audience: CRED customers using Microsoft Dynamics 365 Sales as their CRM.

Purpose: Cover the day-one operational questions for Dynamics — sync cadence, manual triggers, enrichment vs sync, troubleshooting fields that fail to pass over, and where to find action logs.

Read this first: CRED × CRM — How the integration works in the CRED UI. That article covers the cross-CRM concepts. This one covers Dynamics-specific behaviour.

Quick answers

1. What CRED syncs from Dynamics 365

CRED supports 13 entity types on Dynamics 365 Sales. Most read-only entities are coming online incrementally as we expand bidirectional support.

Bidirectional today: Account, Contact, Opportunity. Other entities are read-only into CRED for now — if you need write-back on Tasks, Leads, or Notes, please file a request with your CSM.

Sandbox vs Production: Both are supported. Datacenter region (NA, EU, UK, Asia, etc.) is auto-detected from your Dynamics environment URL.

Pipelines: Dynamics models pipelines as Business Process Flows (BPFs). CRED reads them via the workflow entity plus a synthetic salesstage pipeline derived from the picklist values on opportunity. So even orgs without BPFs see a usable pipeline in CRED.

2. When and how often CRED syncs with Dynamics

Initial sync

Triggered immediately after OAuth completes. CRED runs DATA_SYNC_READ for each entity type in tier order. Tier 0 entities (Users, Accounts, Contacts, custom entity metadata) start immediately with a 4-minute stagger. Subsequent tiers are dispatched automatically as each Phase-2 ingestion completes.

For large orgs (1M+ accounts) the initial sync can run for several hours. Progress is in Settings → Integrations → Microsoft Dynamics → Sync log.

Ongoing incremental sync

• OData queries filter by modifiedon ge the last sync timestamp.

• A new pass is queued shortly after the previous one finishes — new and modified records typically arrive in CRED within a few minutes.

• Deletions in Dynamics surface via OData change-tracking when enabled. If you need deletions tracked, ask your Dynamics admin to enable change tracking on the relevant entities (Setup → Customizations).

• If a read task hangs > 15 min it auto-restarts. Failed Phase-2 records retry after 4h.

Rate-limit awareness — Dynamics is the strictest of the three CRMs

Dynamics 365 enforces per-user service protection limits:

• 60 requests / minute per user

• 10,000 requests / 5 minutes per user

• 52 concurrent requests per user

• Plus a per-license daily entitlement (10k for Professional, 100k for Enterprise)

Because limits are per user, having a dedicated CRED Integration User in Dynamics avoids contention with day-to-day CRM users. CRED watches the x-ms-ratelimit-burst-remaining-xrm-requests response header and slows down before hitting the ceiling. On a 429 we honour Retry-After and resume.

3. How to trigger a manual sync

Dynamics → CRED (pull)

CRED → Dynamics (push)

Currently the supported write targets are Account, Contact, and Opportunity. Other entities are read-only into CRED.

4. Sync vs Enrichment with Dynamics

"Sync with Dynamics" pushes the record's current CRED values to Dynamics. It does not run the CRED enrichment waterfall and does not consume credits. To combine them:

1. Manual two-step: click Enrich, wait for fields to populate, then click Sync with Dynamics.

2. Workflow: Workflows → trigger on list / signal / create → Enrich → Sync to CRM (Dynamics).

3. Auto-enrich on create: Settings → Integrations → Microsoft Dynamics → Enrichment → toggle Auto-enrich on create.

See the cross-CRM article for the full rationale on why these are kept separate.

5. Mapped fields not passing over — Dynamics-specific troubleshooting

Walk the seven-reason cross-CRM checklist first. Dynamics-specific blockers:

Privilege model — the most common Dynamics blocker

Dynamics security is layered: business unit → security role → field-level security profile. CRED writes as the connected user. If that user's security role lacks Write on the entity, the entire write fails. If the role has Write on the entity but a Field Security Profile blocks a specific field, only that field fails.

Recommended setup:

1. Create a dedicated "CRED Integration User" (a non-interactive application user is fine; we support both).

2. Assign a security role with Organization-level Read/Write/Create on Account, Contact, Opportunity, and any custom entities you want to sync.

3. If you use Field Security Profiles, add the integration user to the relevant profiles for any "secured" fields you want CRED to write.

4. Connect CRED as that user.

Business rules & plugins

Business rules and Dynamics plugins fire on every write. Failures from plugins typically come back as generic 0x80040224 server errors with the plugin name in the inner exception. The Sync Log surfaces the inner exception — if you see "plugin" in the error, audit Setup → Customizations → Plug-in Assemblies.

Multi-currency

If your Dynamics org has multiple currencies, every Opportunity has a transactioncurrencyid. CRED preserves the source currency and converts to the connection's default currency for display.

6. Action logs

Same four locations as every CRM. Dynamics specifics:

• Record Activity tab in CRED shows the Dynamics GUID for every sync attempt — copy it into your Dynamics URL (.../main.aspx?etn=account&id={guid}) to jump to the record.

• Each error log entry includes the Dynamics errorCode (e.g. 0x80040216) and the inner exception message.

• Dynamics-side, Audit History on each record (must be enabled per entity in customisations) shows who changed what. CRED writes appear as the connected user.

• If a sync repeatedly hits 0x80040265, your connected user is competing with another app on the same login — switch CRED to a dedicated user.

7. Dynamics integration limits and known constraints

Things that look like a sync bug but aren't

• Write-back is currently limited to Account / Contact / Opportunity. Tasks, Leads, Notes, Emails are read-only into CRED today.

• Business Process Flows: CRED reads the BPF stage but doesn't advance the BPF when an Opportunity stage changes. Stage advancement still happens in Dynamics.

• Synthetic salesstage pipeline: Orgs without explicit BPFs see a built-in pipeline derived from the salesstagecode option set. This is a CRED convention, not a Dynamics object — it doesn't appear in Dynamics.

• Activity entities (task, email, phonecall) are polymorphic in Dynamics. CRED currently maps the regarding link to Account/Contact/Opportunity only.

8. Reference — CRED-side technical detail

• Library: dynamics-web-api (TypeScript)

• API version: 9.2 (OData v4)

• Auth: OAuth 2.0 via Microsoft Entra ID (Azure AD). Tokens refreshed before every call (Microsoft's recommended pattern)

• Datacenter regions: North America, Europe, UK, Asia, Australia, Japan, India, Canada, GCC, GCC High — auto-detected from the environment URL

Useful Microsoft links

• Web API overview

• Service protection limits

• OData query options

• Application users