A successful AI agent pilot can demonstrate clear business value, but expanding the agent across Dynamics 365 ERP and CRM introduces a different set of considerations. As agents begin to access shared data, update records, and influence connected processes, organizations need control over identity, permissions, data, integrations, actions, and accountability. The practical path forward is to establish these controls early, then scale proven patterns across Finance, Supply Chain, Sales, Customer Service, Power Platform, and Azure.
Imagine a sales team has piloted an agent that identifies promising opportunities and prepares follow-up activities. It works well, and users trust its recommendations. The natural question follows: Where else can we use this?
Perhaps finance wants an agent to flag invoice exceptions. Customer Service wants one to summarize cases. Supply Chain wants assistance with purchasing decisions. Before long, several agents are working with the same customers, products, orders, suppliers, and financial records. That is where the nature of the problem changes.
A single pilot can operate within a narrow process, with limited data access and close human supervision. Several agents working across Dynamics 365 Finance, Supply Chain Management, Sales, Customer Service, and the Power Platform create dependencies among processes that were previously managed separately. Understanding how Dynamics 365 Business Central AI agents operate across core workflows provides a blueprint for managing automated task handoffs without compromising data integrity.
Consider a simple sales example. An agent identifies an opportunity and recommends a discount. The opportunity may become an order, which then passes through pricing, credit, inventory, tax, and fulfillment rules in Dynamics 365. The agent can contribute to that process, but should not quietly sidestep the controls governing it.
Scaling agents, therefore, is as much a process and governance exercise as a technology one. Before adding another agent, organizations should understand who owns the process, what data the agent can access, what actions it can perform, and where human judgment remains necessary.
Give every agent an identity and a boundary
The first control is surprisingly basic: know what exists.
As agent deployments grow, organizations should maintain a clear inventory covering:
- The agent’s business purpose and process.
- Its accountable owner and business team.
- Applications, data sources, APIs, and tools it can access.
- Actions it is permitted to perform.
- Its current version and status.
- Its risk classification and approval requirements.
Each agent should also operate through a distinct identity with only the permissions required for its role. Dynamics 365 security roles and Microsoft Entra provide the foundation for applying these boundaries.
A sales forecasting agent may require access to opportunity and order information. It has little reason to alter credit limits or post financial transactions. A customer-service agent may update a case but requires approval before issuing a refund.
This distinction between seeing, recommending, and acting becomes increasingly important as autonomy grows.
It is also worth reviewing the existing Dynamics 365 security model before introducing agents. Years of ERP and CRM changes can leave behind permissions that made sense individually but become questionable when assigned to automated actors.
The agent is only as reliable as the business context it receives
An agent can only make a sound decision when the surrounding information is trustworthy.
This becomes especially important when ERP and CRM systems share business processes. Customer, product, pricing, inventory, order, and service information may originate in different applications, each with its own ownership and validation rules.
Before scaling, organizations should establish the following:
- Clear ownership for master data
- Consistent definitions across ERP and CRM
- Validation rules for agent-created or updated records
- Controlled APIs and integration pathways
- Exception handling and retry procedures
- Auditable write-backs
- Protection for financial, customer, employee, and commercially sensitive data
Returning to the discount example, a CRM agent might identify a discount opportunity and recommend an action. The subsequent order should still pass through the appropriate Dynamics 365 pricing, credit, approval, and fulfillment controls.
That distinction matters because integration is not simply about moving data from one system to another. It is about preserving the rules that give the data business meaning.
For organizations working across Dynamics 365, Power Platform, Azure, and other applications, well-defined integration patterns are especially important. An agent should have a controlled route into a process rather than an open door into the underlying systems.
Decide what an agent may actually do
The most useful question before granting an agent more autonomy is not “Can it perform this task?” It is “Under what conditions should it be allowed to?”
A practical action model can divide agent activity into five levels:
| Action level |
Example |
Expected control |
| Read-only |
Retrieve account history or summarize open cases |
Role-based access and activity logging |
| Low-risk update |
Update a validated CRM activity |
Business-rule validation and audit trail |
| Threshold-based |
Apply a discount within an approved limit |
Defined value limits and approval-policy checks |
| Approval required |
Issue a refund or change a credit limit |
Named human approval and evidence capture |
| Restricted |
Post high-risk financial entries |
Human-only action or controlled workflow |
The thresholds should reflect the organization’s approval matrix, segregation-of-duties requirements, financial exposure, customer impact, and regulatory obligations.
Then comes visibility. If an agent changes a record, teams should be able to establish:
- What triggered the action
- What information and policy it used
- Which tools or APIs it called
- What decision it made
- Whether approval was obtained
- Which Dynamics 365 records changed
- What the final outcome was
Monitoring should also identify unusual transaction volumes, repeated failures, unexpected access, and policy violations. Every production agent should have a practical way to be paused or restricted when something goes wrong.
That may sound obvious. In practice, it is much easier to approve an agent than to answer “Why did it do that?” three months later.
Scale through patterns, not one-off projects
Once the controls are in place, organizations can expand agent usage without treating each new use case as an entirely new exercise.
A measured progression might look like this:
- Prove one use case
Define success measures, exception handling, ownership, and acceptable risk before deployment.
- Introduce limited action
Allow low-risk, reversible activities once the agent has demonstrated reliable performance.
- Reuse proven patterns
Apply established security roles, integration methods, testing procedures, audit standards, and release controls to related processes.
- Connect agents carefully
When several agents need to work together, define task handoffs, decision authority, shared context, and escalation paths before orchestrating.
- Review continuously
Monitor permissions, incidents, data quality, business outcomes, and agent performance before further increasing autonomy.
This approach has a useful side effect. Each successful deployment contributes to a reusable operating model across Dynamics 365 ERP, CRM, Power Platform, Azure integration services, data platforms, and AI capabilities.
For organizations working with LevelShift, this is also where an experienced Dynamics 365 integration partner can add practical value: by establishing repeatable architecture, security, integration, and governance patterns so that each new agent does not require the organization to reinvent its approach.
Conclusion
AI agents can reduce repetitive work, improve responsiveness, and make better use of the information already available across Dynamics 365. The opportunity is substantial, but the path from a single successful pilot to a network of agents requires more than adding new use cases.
Organizations that establish clear identities, appropriate permissions, trustworthy data, controlled integrations, defined action boundaries, and proper monitoring can expand agent autonomy without surrendering oversight.
The objective is not to create a perfect enterprise-wide AI strategy before taking another step. It is to ensure each step is sufficiently controlled so that the next can be taken with confidence. For organizations planning that transition, aligning agent design with Dynamics 365 processes, security roles, integration architecture, and business governance provides a practical path from a successful pilot to scalable ERP and CRM automation.
Leveraging dedicated Dynamics 365 Business Central consulting services helps enterprise teams audit existing security models, design API boundaries, and establish repeatable AI governance.
