CRM integration guide
Microsoft Dynamics 365 + UbiGrowth workflows
Microsoft Dynamics 365 is Microsoft's enterprise business application suite, where CRM data sits alongside ERP and the wider Microsoft identity and productivity estate. This guide covers the records that matter, how the connection should be scoped, and what the first bounded workflow should be.
Introduction
Make Microsoft Dynamics 365 part of the workflow, not another silo.
Validate connector availability for your workspace
This guide covers how a team designs a CRM workflow around Microsoft Dynamics 365 with UbiGrowth: which records stay authoritative, how the connection should be scoped, what the first bounded workflow should be, and how to tell whether it worked.
The records that matter are Account, Contact, Lead, Opportunity, Activity, and Business Unit. Dynamics scopes record visibility through Business Units and security roles, so two integrations authenticated as different service accounts legitimately see different pipelines. Identity resolution has to account for who is asking, not only which record matched.
Microsoft Dynamics 365 is not currently on UbiVibe's verified connector list. This page is an implementation design reference: use it to specify the workflow, then validate whether the connection is available and correctly scoped for your workspace before you make it a dependency. The verified UbiVibe connections today are Salesforce, HubSpot, Gmail, Google Drive, Slack, and GitHub.
Grow is the usual destination for this connection, because the value shows up as outreach, reply handling, scheduling, and pipeline execution against the connected records.
Why teams evaluate this connection
Integrations create value when they remove operating friction.
The first design decision is not which API endpoint to call; it is which system owns the record, what event should trigger work, who owns the exception path, and what successful completion means.
The recurring failure with a Microsoft Dynamics 365 integration is not connectivity. It is that the CRM ends up holding a record of what someone remembered to log, while the work itself happened in an inbox, a call, a spreadsheet, and a separate AI tool that never saw the account.
When that gap exists, everything built on top of it inherits it. Forecasts describe logged activity rather than real activity, outreach is written without the reply history that would make it relevant, and the team spends its day reconciling systems instead of working accounts.
You're likely here because
- Pipeline data is only as current as the last time someone logged activity
- Outreach is generated without the account history that would ground it
- The same account context is rebuilt in several tools each day
Record model
What a Microsoft Dynamics 365 integration actually reads and writes.
Integration design starts from the objects the system really exposes, not from a generic connector diagram. These are Microsoft Dynamics 365's.
Identity and matching
Dynamics scopes record visibility through Business Units and security roles, so two integrations authenticated as different service accounts legitimately see different pipelines. Identity resolution has to account for who is asking, not only which record matched.
Start here
Read Opportunities owned by one Business Unit with a close date inside the quarter and no recent Activity, and prepare the next step for the owning rep.
What this will not do
It will not span the ERP side automatically. Dynamics 365 Finance and Operations is a separate application with its own data model; a CRM connection does not reach orders or ledger entries.
The constraint to plan around
Dataverse enforces per-environment API request limits and rejects bulk operations that exceed them, and sandbox and production environments carry different customizations, so a validated integration can still fail on promotion.
Build notes
What you actually have to reason about in Microsoft Dynamics 365.
The fields that carry meaning, how the connection authenticates, and whether the event surface can be trusted. This is the part that decides whether the integration works in month three.
| Field | Why it matters |
|---|---|
| statecode / statuscode | a two-level state model where statuscode is scoped to statecode — reading one without the other misreports the record |
| ownerid | polymorphic across user and team, and the basis of Business Unit visibility |
| estimatedclosedate | drives forecast rollups and is frequently left at its default |
| modifiedon | the incremental cursor, though Dataverse change tracking is the supported mechanism |
| transactioncurrencyid | multi-currency orgs store both base and transaction amounts, and reporting on the wrong one is a silent error |
Authentication
Entra ID app registration with either delegated or application permissions against Dataverse, plus an application user created inside the environment with a security role. Registering the app is not enough — without the application user and role, every call returns a permission error that looks like a bad credential.
Events and delivery
Dataverse change tracking supports reliable incremental reads; webhooks and Service Bus endpoints support push. Plugins can run synchronously in the transaction, which means your write can be rejected by code the customer wrote and you cannot see.
Workflow
How the Microsoft Dynamics 365 workflow runs.
The operating sequence, from reading the source system through to the result landing back where it belongs.
Step 01
Read the pipeline as it stands
The workflow starts from live Microsoft Dynamics 365 accounts, contacts, and opportunities rather than an export, so prioritization reflects today's pipeline.
Step 02
Assemble the account context
Reply history, documents, and prior activity are brought together so the next action is grounded in what actually happened with the account.
Step 03
Decide the next action
ARIA proposes the specific next step for the account, with the supporting context attached, instead of producing a message with no stated reason.
Step 04
Execute through Grow
Outreach, reply handling, and scheduling run against the same record, staged for review while the motion is being proven.
Design decisions
The CRM decisions this connection forces.
Each of these has to be settled before the Microsoft Dynamics 365 workflow is allowed to write anything.
Step 01
Resolve the account identity
Decide how a person and a company are matched between Microsoft Dynamics 365 and the rest of the stack before any write happens. Most CRM integration damage is duplicate records created by a weak match rule.
Step 02
Keep execution attached to the opportunity
Outreach, replies, meetings, and stage changes should resolve back to the same opportunity, so the CRM reflects what actually happened rather than a parallel activity log.
Implementation path
How to implement the Microsoft Dynamics 365 workflow.
- 01
Decide which fields Microsoft Dynamics 365 owns and which the workflow may write, and write that decision down before enabling anything.
- 02
Define the identity match rule for contacts and companies, including what happens on an ambiguous match.
- 03
Start read-only. Prove that the workflow reads the right records before it is allowed to change any of them.
- 04
Once the stale-opportunity queue is trusted, extend it across Business Units so a regional manager sees their own slice without a separate report being built.
Governance
Controls that matter.
Control 01
CRM write scopes are limited to the specific objects the workflow needs, never blanket admin access.
Control 02
Duplicate creation is treated as a defect, not an acceptable side effect of syncing.
Control 03
Stage changes and closed-won updates stay under human control; automation prepares them rather than deciding them.
Failure modes
How a Microsoft Dynamics 365 integration breaks in production.
Not generic integration advice. These follow from how this system actually behaves, which is why they look nothing like the list on the next guide over.
Symptom 01
Every request returns a permission error despite a correctly registered app.
Cause
The app registration exists in Entra ID but no application user with a security role was created inside the environment.
Fix
Create the application user and assign a role built for the integration, and verify against the environment rather than the tenant.
Symptom 02
An integration validated in sandbox fails on promotion to production.
Cause
Environments carry different customizations, plugins, and business rules.
Fix
Validate against a production-like environment with the same solution layers, and surface the platform's own error rather than wrapping it.
Symptom 03
Bulk writes time out inconsistently.
Cause
A synchronous plugin runs inside the write transaction and its duration varies with the payload.
Fix
Use batch operations with smaller payloads, and treat a timeout as unknown rather than failed — re-read before retrying.
What changes at scale
Dataverse applies service protection limits per user per environment, counting requests, execution time, and concurrency separately. Exceeding any of them returns a retry-after that must be honoured rather than retried immediately.
Examples
What a working Microsoft Dynamics 365 workflow looks like.
Bounded scenarios rather than a feature list. Each one can be verified against work the team already does.
Account context
With Microsoft Dynamics 365 connected, ARIA works from live account, contact, and opportunity records instead of an export, so prioritization reflects the pipeline as it stands today.
Grounded outbound
Grow drafts outreach against the account history already in Microsoft Dynamics 365, so the message references what actually happened with the account rather than a generic template.
Limitations and considerations
What to validate before you depend on this.
- Dataverse enforces per-environment API request limits and rejects bulk operations that exceed them, and sandbox and production environments carry different customizations, so a validated integration can still fail on promotion.
- Business rules, plugins, and workflows execute on write inside the platform transaction. A write that violates one is rejected wholesale, and a write that triggers a slow plugin can time out — leaving the caller unsure whether it committed.
- When the requirement is really the ERP side. Finance and Operations is a separate application with a separate data model, and reaching it through a CRM connection is not possible regardless of how the licence is packaged.
- If Microsoft Dynamics 365 data is incomplete, the workflow inherits that gap. Connected context is not automatically accurate context.
- Custom objects, custom fields, and heavily-customized permission models change what an integration can safely do; validate them against your own instance rather than the vendor default.
FAQ
Microsoft Dynamics 365 integration questions.
What records does a Microsoft Dynamics 365 integration actually work with?
The primary records are Account, Contact, Lead, Opportunity, Activity, and Business Unit. Dynamics scopes record visibility through Business Units and security roles, so two integrations authenticated as different service accounts legitimately see different pipelines. Identity resolution has to account for who is asking, not only which record matched.
What should the first Microsoft Dynamics 365 workflow be?
Read Opportunities owned by one Business Unit with a close date inside the quarter and no recent Activity, and prepare the next step for the owning rep.
What will a Microsoft Dynamics 365 integration not do?
It will not span the ERP side automatically. Dynamics 365 Finance and Operations is a separate application with its own data model; a CRM connection does not reach orders or ledger entries.
What is the main constraint to plan around?
Dataverse enforces per-environment API request limits and rejects bulk operations that exceed them, and sandbox and production environments carry different customizations, so a validated integration can still fail on promotion.
What changes about a Microsoft Dynamics 365 integration at scale?
Dataverse applies service protection limits per user per environment, counting requests, execution time, and concurrency separately. Exceeding any of them returns a retry-after that must be honoured rather than retried immediately.
How does authentication work for Microsoft Dynamics 365?
Entra ID app registration with either delegated or application permissions against Dataverse, plus an application user created inside the environment with a security role. Registering the app is not enough — without the application user and role, every call returns a permission error that looks like a bad credential.
Does Microsoft Dynamics 365 support webhooks, and can they be trusted?
Dataverse change tracking supports reliable incremental reads; webhooks and Service Bus endpoints support push. Plugins can run synchronously in the transaction, which means your write can be rejected by code the customer wrote and you cannot see.
What is the risk of writing to Microsoft Dynamics 365?
Business rules, plugins, and workflows execute on write inside the platform transaction. A write that violates one is rejected wholesale, and a write that triggers a slow plugin can time out — leaving the caller unsure whether it committed.
When is connecting Microsoft Dynamics 365 the wrong call?
When the requirement is really the ERP side. Finance and Operations is a separate application with a separate data model, and reaching it through a CRM connection is not possible regardless of how the licence is packaged.
What should a Microsoft Dynamics 365 integration automate first?
Start with one bounded workflow that removes a measurable handoff, duplicate-entry step, reporting delay, or follow-up gap. Expand only after the first workflow is reliable.
Does UbiGrowth require Microsoft Dynamics 365 to be replaced?
No. The operating model is designed around connecting to systems that should remain authoritative and building workflows around them rather than forcing a wholesale replacement.
Is connector availability identical for every workspace?
No. Availability can depend on provider configuration, authentication, scopes, workspace setup, and deployment state. Validate the required connection before treating it as an operational dependency.
Will this create duplicate records in Microsoft Dynamics 365?
Only if the identity match rule is weak. Define how people and companies are matched, and how ambiguous matches are handled, before enabling any write path.
Does Microsoft Dynamics 365 stay the system of record?
Yes. The design assumption is that Microsoft Dynamics 365 remains authoritative for the objects it owns and the workflow builds around it rather than replacing it.
Can pipeline stages be updated automatically?
Stage progression should stay under human control. Automation can prepare and propose the update, but deciding that a deal moved is a judgment call.
How this access is governed
What ARIA is allowed to do in Microsoft Dynamics 365, and who decides.
Connecting Microsoft Dynamics 365 is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to run this integration.
Describe the outcome you need across this system. ARIA works out the scopes, data, and actions the job requires, and operates inside the access you grant — which you can change or revoke.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn the integration into a working business outcome.
Start with ARIA to describe the outcome, then continue into the product path that fits the workflow. Connector availability and required scopes should be validated for the specific workspace before production use.