Your First AI Initiative in Dynamics 365 Should Be Smaller Than Your Ambition

The conversation about artificial intelligence in ERP often begins at the wrong end.

A team watches an impressive demonstration. Someone asks whether an agent could handle collections, manage purchasing exceptions, or accelerate financial operations. Before long, the discussion shifts to tools, integrations, and deployment dates.

What is too often missing is the most important question: Which part of the work are we actually trying to improve?

As a solution architect, I would rather begin with a narrow, well-defined business problem than a sweeping promise of transformation. A sound first AI initiative should make a specific task easier, produce a result the business can verify, and preserve the controls that make the underlying process trustworthy.

For organizations working within Dynamics 365 Finance and Supply Chain Management (commonly referred to as D365 F&SCM), the opportunity is substantial. Microsoft documents embedded summaries, conversational assistance, and agent capabilities throughout the finance and operations application landscape. However, these capabilities differ meaningfully in purpose, prerequisites, availability, and operational scope and should never be treated as a single interchangeable AI solution.

The foundation of a successful start is accountability: a clear understanding of what the technology may do, what people must verify, and who owns the outcome.

Begin Where the Work Is Difficult

A business process is usually too large to serve as a first AI use case.

Before selecting a feature, I recommend working through five questions:

1. Who performs the task?
   
2. What information do they need?
   
3. Where does the current effort or delay occur?
   
4. What would an acceptable AI-assisted result look like?
   
5. Which decisions or actions must remain outside the initial scope?

If those answers remain unclear, the team is not yet ready to configure a solution. It is ready to clarify the process.

Separate Understanding From Acting

One of the most consequential design mistakes is treating every AI interaction as equivalent.

Microsoft distinguishes among sidecar experiences, embedded experiences, and capabilities that operate outside the application. These distinctions describe different interaction patterns; they do not establish identical permissions or transaction authority.

For implementation planning, I rely on a separate, practical framework:

Intended outcome	What the solution does	What the design must establish
Explain	Answers a question or provides guidance	Whether the answer applies to the organization’s configuration and procedures
Summarize	Condenses selected information	Whether material facts remain accurate and complete
Draft	Prepares a proposed communication or recommendation	Who reviews it and authorizes its use
Act	Performs a business operation	Which identity, permissions, approvals, and recovery controls apply

This is an architectural assessment framework, not a Microsoft product classification.

Its purpose is to prevent scope from expanding unnoticed. A project that begins with “summarize overdue balances” should never quietly become “send collection notices without review.”

When the requested behavior changes, the control design must change with it.

Look Inside the Product Before Building Outside It

Custom development should address a demonstrated gap, nothing less.

Before introducing an agent, an external knowledge source, or an additional integration, evaluate the capabilities Microsoft already provides. Its documentation includes generative help and guidance, collections summaries, and Supply Chain Management summaries for areas such as purchase orders, vendors, and workflow history.

A disciplined fit-gap assessment should examine the actual user task:

• Does the standard capability use the information the user needs?
  
• Does it appear at the right point in the workflow?
  
• Can the user validate its output?
  
• Does it operate within the required application and security context?
  
• What remains unresolved?

A custom solution may be justified when the process spans systems, requires additional approved knowledge, or needs an interaction the standard feature does not support. Even then, document why the added capability justifies the additional ownership, testing, and support obligations it introduces.

Treat Readiness as an Architecture Review

A visible Copilot button is not evidence that an environment is ready for its intended use case.

Microsoft’s enablement guidance describes finance and operations Copilot capabilities as a combination of application components and Azure-hosted AI services connected through Dataverse via Power Platform Integration. It also clarifies that Power Platform Integration does not require dual-write to be enabled unless dual-write is needed for the implementation.

That distinction matters. Do not introduce a data synchronization pattern merely because an AI feature depends on Dataverse.

Readiness should be confirmed for the specific capability under consideration.

Readiness area	What to verify
Application	Supported version, updates, and feature-specific prerequisites
Environment	Supported environment type and deployment approach
Power Platform	Integration status, associated Dataverse environment, and required solutions
Configuration	Feature management settings and additional setup
Availability	Supported geography, language, and release status
Commercial model	Applicable licensing, capacity, and billing requirements
Operations	Administration, monitoring, support, and change ownership

Microsoft documents distinct setup requirements for shared Copilot experiences, Finance summaries, Supply Chain Management summaries, and agent management. Requirements should therefore be verified individually rather than copied from a prior AI project. Microsoft also states that Copilot and AI agents are not supported in developer environments deployed through Lifecycle Services.

The practical lesson is straightforward: validate the environment before committing to a pilot date.

Define Data Readiness Around the Selected Task

An AI initiative does not need to wait for every data issue across the enterprise to be resolved. It does need a precise understanding of the data required for its chosen task.

For a collections pilot, the relevant questions include:

• Are payments and settlements current?
  
• Are users reviewing the correct customer and legal entity?
  
• Are relevant dates, amounts, and currencies well understood?
  
• Are customer contact details maintained?
  
• Can the reviewer reconcile the generated summary to the underlying records?

The Collections coordinator summary draws on financial information such as overdue invoices, payment history, and aged balances. These inputs should form part of the pilot’s validation process.

A purchasing pilot requires a different kind of review. Microsoft’s purchase order summaries describe order progress using information associated with purchase order lines and their status. Testing should therefore include the records that support those statements, including relevant confirmation, receipt, and invoice information.

Do not assume that information influences an AI result simply because it exists somewhere within the organization.

A supplier commitment captured in an email, a dispute recorded in a spreadsheet, or an exception discussed in a meeting may matter a great deal to the business. The team must establish whether the selected feature actually has access to that information and uses it.

Where important context falls outside the feature’s scope, document the limitation and retain the corresponding human review.

Test Permissions Through Real User Roles

Security testing should answer more than “Can the user open the feature?”

Microsoft states that Dynamics 365 and Power Platform Copilot data access is based on the current user’s access level. Its Supply Chain Management AI summary documentation further describes access as limited by the user’s security roles and permissions.

Those statements provide a sound foundation for standard capabilities. They do not replace implementation testing, and they should not be generalized to every custom integration.

For a custom agent, review the authentication and authorization behind each connection and action. Establish whether it operates through a user connection, a shared connection, or an application identity, then test the permissions actually applied.

My recommended test scenarios include:

• An authorized user requesting permitted information.
  
• A user requesting information from an unauthorized legal entity.
  
• A read-only user attempting an update.
  
• A user attempting to initiate and approve the same controlled activity.
  
• A request for sensitive information outside the intended scope.
  
• An attempt to achieve a restricted action through alternate wording.

Do not approve the security design simply because an administrator successfully completed a demonstration.

The design must hold up for the operational roles that will actually use it, including the requests it must refuse.

Review the Data Flow Before Approving the Experience

Privacy discussions demand precision.

Microsoft documents that geographic availability varies and that some generative AI capabilities may require permission for cross-region processing. When such movement is permitted, prompts and results might be processed outside the environment’s region.

Microsoft also states that this data is not used to train, retrain, or improve Azure OpenAI Service foundation models. That assurance addresses an important concern, but it does not answer every question about a particular solution’s data flow.

For each implementation, document:

1. What information enters the AI service.
   
2. Which services and environments process it.
   
3. Whether cross-region processing is involved.
   
4. Which external connectors or knowledge sources participate.
   
5. What logging and retention apply.
   
6. Who can access the resulting artifacts.
   
7. Which organizational approvals are required.

Do not reuse a privacy conclusion drawn for an embedded summary when assessing a custom agent. Different connections and knowledge sources can change the assessment entirely.

Make Business Verification Part of Testing

A response can sound entirely reasonable and still be unsuitable for the task.

Testing must compare the output against an agreed source of truth, not merely assess whether the wording is convincing.

For a collections summary, I would verify customer identity, amounts, currency, dates, overdue status, and statements about payment behavior. For a draft reminder, I would also review tone, unsupported assertions, and whether the message reflects the approved collections process. For a purchase order summary, I would compare the narrative with the relevant line-level records and investigate whether an omitted exception could change the buyer’s next action.

A practical evaluation set should include:

Test category	Purpose
Normal cases	Confirm usefulness in routine work
Exceptions	Evaluate partial payments, credit notes, disputes, missing dates, and incomplete records
Access boundaries	Confirm permitted access and appropriate denial
Ambiguity	Check whether uncertainty leads to review rather than an unsupported conclusion
Service interruption	Confirm the manual fallback
Repeated requests	For action-taking solutions, assess duplicate-action prevention and recovery

These are recommended test categories; their exact content should follow the selected process and architecture.

Retain the evaluation set so it can be reused after material changes. Testing should become part of the operating model, not a one-time activity performed before the demonstration.

The Dos and Don’ts That Matter Most

The following recommendations help keep a first initiative controlled and genuinely useful.

Do	Don’t
Select one task with a named business owner.	Begin with an undefined ambition to automate a department.
Assess standard capabilities first.	Make a custom agent the default solution.
Confirm prerequisites for the exact feature.	Assume all Copilot experiences share the same requirements.
Validate with realistic operational roles.	Rely on administrator testing.
Make source-record verification explicit.	Treat polished language as proof of accuracy.
Document excluded actions.	Let the pilot acquire financial authority through scope creep.
Review the actual data flow.	Make blanket claims about residency or privacy.
Measure correction effort as well as speed.	Count prompts as evidence of business value.
Assign support and suspension ownership.	Assume the project team will remain the permanent support model.
Reassess controls before adding execution.	Treat summarization success as authorization for autonomy.

Build a Capability the Business Can Own

The first AI implementation in D365 F&SCM should leave behind more than a configured feature.It should leave behind an agreed process boundary, a tested security model, a repeatable evaluation method, a support owner, and a clear explanation of what people must still verify. That is what makes the initiative sustainable.

Start with a task small enough to understand. Use supported capabilities where they fit. Keep authority deliberate. Measure the work honestly.

The ambition can remain large. The first release should be precise.