Skip to content
FR

Orchestrate Prebuilt Agents and Apps

Step 13 of 22

Prebuilt AI Agents in Dynamics 365, Microsoft 365, and Power Platform

Prebuilt AI agents in Dynamics 365, Microsoft 365, and Power Platform can shorten implementation when their supported capabilities match the business process. For AB-100, this lesson covers Orchestrate configuration of prebuilt agents and apps within Design AI-powered business solutions (25–30% in the course outline before the announced November 16, 2026 update). You will compare configure, extend, and build options, connect trusted knowledge, and verify permissions and release status before rollout.

Learning objectives

After this lesson you can:

  • Decide when to configure a prebuilt agent, extend it, or build a custom one.
  • Describe the AI features of Dynamics 365 apps for finance and supply chain, and for customer experience and service.
  • Propose Microsoft 365 agents for a business scenario.
  • Explain how Copilot for Sales and Copilot for Service are configured and which data and knowledge sources they use.
  • Place Power Platform AI features (AI hub, AI Builder, prompts) in a solution.
  • Design interoperability so finance and operations agent chats can use additional knowledge sources.

1. Configure first, extend second, build last

A recurring architectural principle in AB-100 is to prefer the least custom option that meets the requirement.

Option Use it when Trade-off
Configure a prebuilt agent or Copilot The scenario matches a shipped capability (summarize a case, draft a sales email, chat with finance data) Fastest and supported; limited by what the feature exposes
Extend it (Copilot Studio, plugins, MCP, connectors) The prebuilt feature is right but needs extra knowledge, actions or channels Moderate effort; you own the extension's lifecycle
Build a custom agent (Copilot Studio or Foundry) No prebuilt capability fits, or the process is unique to the business Most flexibility, highest cost of ownership

Orchestration here means combining these pieces so that they behave as one solution: which agent handles which task, which data each can see, and how they hand work to each other.

2. Dynamics 365 AI features

Finance and supply chain

Copilot capabilities in Dynamics 365 finance and operations apps are enabled by an administrator and work on the data and business logic of the application. Typical scenarios include:

  • Chat with finance and operations data (preview): users ask questions grounded in supported structured-data sources. Configure the data and authentication path; enabling a sidecar does not automatically expose every finance table.
  • Summaries and insights on records such as purchase orders, vendor invoices or collections.
  • Agent-driven business processes that automate repetitive work (for example, matching and processing supplier communications or reconciling data).
  • Extensibility: developers can expose business logic to agents, and the Dynamics 365 ERP Model Context Protocol (MCP) server exposes supported data operations and business logic to compatible clients. Its requests retain application authorization and validation; MCP is not direct database access.

Architect's checklist: enable the feature in the right environment, confirm the data-residency and Copilot data-movement settings, review security roles (the agent must not widen access), and decide which actions an agent may take without human approval.

Customer experience and service

Dynamics 365 Customer Service and Contact Center provide AI across the case lifecycle:

  • Copilot in the agent workspace: summarize a case or conversation, suggest replies, and draft knowledge-grounded answers for human representatives.
  • Agents for service operations: agents such as case management, customer intent, quality evaluation and customer knowledge management, which classify requests, route work, evaluate conversations and turn resolved cases into knowledge articles. Availability and maturity of individual agents differ (some are generally available, others in preview), so confirm release status before proposing one.
  • Copilot Studio agents in Contact Center: build a customer-facing agent once in Copilot Studio and reuse it across channels with consistent governance, handing off to a human representative with context when needed.
  • Dynamics 365 Sales: lead and opportunity summaries, email drafting, and next-step suggestions inside the seller's flow.

The architect's main decisions are the escalation path (when the agent hands over to a human), the knowledge sources the agent may cite, and how quality is measured afterwards.

3. Microsoft 365 agents for business scenarios

Microsoft 365 Copilot is the common surface for many prebuilt agents. When proposing agents, map the scenario to the right type:

Scenario Candidate Notes
Research, analysis, or summarization across mail, files and meetings Microsoft-provided agents in Microsoft 365 Copilot Grounded in Microsoft Graph; honors existing permissions
Team-specific Q&A over a SharePoint library Declarative or SharePoint-based agent Knowledge limited to chosen sites or files
Seller or service-rep productivity inside Outlook and Teams Copilot for Sales / Copilot for Service Connect to a CRM and knowledge sources
Governed distribution of agents to employees Agent catalog and admin controls in the Microsoft 365 admin center Admins approve, block or assign agents

For user-grounded Microsoft 365 content, existing permissions constrain retrieval. Oversharing occurs when those permissions already grant excessive access; a label’s presence alone does not prove that access is restricted. Audit permissions and the protections actually configured for labels before rollout. Separately review custom tools: an app-only or maker-provided connection may use a different identity from the person chatting.

4. Sales agent and Service Agent: connect CRM data

AB-100 materials also use the names Copilot for Sales and Copilot for Service. Current documentation describes Sales agent and Service Agent experiences. Match the exact product, host, license, and connected environment rather than assuming identical capabilities across all these names.

Sales agent (Copilot for Sales in earlier material)

  • Connects to Dynamics 365 Sales or Salesforce as the CRM.
  • Brings customer context into Outlook and Teams: meeting preparation, email summaries and drafts, CRM updates from conversation.
  • Configuration choices: which CRM and environment, which fields and records are available, which users get licenses, and what can be written back automatically.

Service Agent in Customer Service

  • Helps representatives find, summarize, and update Dynamics 365 Customer Service information from the selected environment; connected knowledge broadens the evidence available to answers.
  • Can combine service data with supported knowledge sources, including Dynamics 365 and SharePoint content. Verify separate integration support for any other case-management system rather than assuming every connector exposes case-update actions.
  • Configuration choices: selected Customer Service environment, supported sources, case-update permissions, and feedback. Define an explicit policy for conflicting sources; this is a solution rule, not a universal product setting called “order of trust”. Installing or assigning the Service app does not itself grant access to customer records.

Common design rule: connect the minimum set of high-quality knowledge sources first. Adding every repository degrades answer relevance and increases the chance of exposing outdated or restricted content.

5. Power Platform AI features

Power Platform provides the low-code layer where prebuilt AI is combined with business logic.

  • AI hub: the place in Power Apps and Power Automate to discover and manage AI capabilities such as prompts and AI models, reducing duplicated effort.
  • AI Builder and prompts: reusable prompts (text generation, extraction, classification, summarization) that can be called from Power Apps, Power Automate flows, or Copilot Studio agents. Prompts can use Microsoft-hosted models or, in supported scenarios, a supported model deployment from Microsoft Foundry.
  • Copilot Studio: agents that use generative orchestration to choose between topics, tools, other agents and knowledge sources.
  • Power Apps and Power Automate with Copilot: describe an app or flow in natural language, and embed agent steps in a process.
  • Administration: admins control which AI features makers can use (for example enabling or disabling AI prompts), use data policies for connectors, and track AI capacity and credits.

Rule of thumb: put deterministic steps (approvals, record updates) in flows, and use AI where the input is unstructured (reading a document, classifying an email, drafting a reply).

6. Interoperability and knowledge sources for finance and operations chat

The finance and operations chat answers from structured application data. Business questions often need more: a policy document, a contract in SharePoint, or data from another system. The design options are:

  1. Add supported knowledge sources to the configured agent. Operational data and procedural help are different use cases; select the documented path for each.
  2. Use a Copilot Studio agent as an orchestrator over supported ERP MCP operations or API tools, alongside document knowledge. Expose the required business capability, not an assumed universal “finance chat” tool.
  3. Choose live access or indexing deliberately. Supported Dataverse virtual entities can expose operational data without replication in the documented data-chat scenario. A native Dataverse copy synchronized by dual-write is another option when justified. Synced Copilot connectors index external content; federated connectors query it live. Each route needs its own permissions configuration.
  4. Delegate only through a supported integration with an explicit contract for identity, inputs, results, and failures. The existence of two chat interfaces does not establish an agent-to-agent integration.

Design checks: interactive ERP MCP requests run in the authenticated user’s security context; an autonomous agent needs its own authorized identity. Preserve finance roles, duties, privileges, and business validations on each request. Document any justified replication, the source of truth, and how conflicting or missing evidence is handled.

Extend in-app help without confusing it with operational data chat

The documented generative help route starts with product documentation. Select the associated Dataverse environment in Copilot Studio and open the finance and operations agent. Add relevant procedural files, wait for Ready, test, and publish. For SharePoint or other knowledge types, the help-extension guidance calls for an authored topic. Start a fresh session after publication.

The help-extension page says finance-and-operations virtual entities are not supported for that route, while the newer operational-data tutorial demonstrates virtual-entity grounding for data questions. Treat these as different documented scenarios and validate the exact environment and capability. Do not assume that adding an inventory table to procedural help is universally supported.

7. Worked example

A distributor wants one assistant for its field sellers and its finance team.

  • Sellers: configure Sales agent on Dynamics 365 Sales, validate the required Outlook and Teams setup, and restrict write-back to the approved record types and permissions.
  • Customer service: configure Service Agent for the selected Customer Service environment with approved knowledge and case actions. Define escalation for missing evidence, explicit customer requests, and high-impact cases; do not rely on an uncalibrated model confidence claim.
  • Finance: use a supported operational-data knowledge path or ERP MCP read operation in a Copilot Studio agent that also retrieves the credit policy with the user’s authorized identity. Confirm preview suitability before rollout.
  • Cross-cutting: use AI hub prompts for invoice-email classification in Power Automate, and review permissions on SharePoint before rollout.

The design starts from prebuilt features and adds only the integrations that testing shows are needed. Use the Copilot Studio topics, tools, and autonomy guidance to define those boundaries.

Step-by-step rollout decision

  1. List the required outcomes separately: seller preparation, case updates, and credit-policy answers. Name an owner and a supported host for each.
  2. Confirm feature status, licensing, region, and required environment integration. An installed app and a published agent are necessary setup steps, not proof that every user can access every capability.
  3. Connect one trusted source at a time. Test a known answer, a missing answer, and a question that should be denied for the test user.
  4. For credit decisions, retrieve live authorized finance facts and cite the applicable policy version. Keep the approval decision in the existing business workflow.
  5. Test the full path across app and identity boundaries, including an expired CRM connection and a failed human transfer. See end-to-end validation of AI business solutions for the corresponding validation approach.

Building a custom agent for every team would add ownership cost before demonstrating a capability gap. Copying all ERP data into SharePoint would introduce a second permission and freshness problem. Buying a license alone would resolve neither issue.

Mini case: readable content with an incorrect policy

A sales representative can open both last year’s credit policy and the current approved policy. The assistant cites the older one. Has permission filtering failed?

Solution: access control may be working correctly while grounding quality fails. Archive or clearly separate obsolete material, assign a source owner, and test version-sensitive questions. If approved sources still conflict, present the uncertainty and route to the policy owner rather than inventing a blended rule. Source access, document currency, and answer correctness are separate checks.

Example: acceptance evidence for a service rollout

For an illustrative pilot of 20 representatives, prepare a small set of cases with known expected outcomes: a permitted case summary, an inaccessible case, a supported status update, and a question with no approved knowledge answer. Record the selected environment, effective identity, cited evidence, and confirmed business result. Expand the pilot only after the team has reviewed failures and assigned an owner to each corrective action. This separates a convincing demonstration from evidence that access controls, source quality, and supported actions work together for the intended users.

Key terms

  • Prebuilt agent: a shipped capability configured within its documented limits.
  • Virtual entity: a Dataverse representation that accesses external operational data without replicating that table.
  • Source of truth: the owned system or approved document that governs a business fact.
  • Oversharing: excessive existing access made easier to discover through search or AI.

Exam tips

  • Prefer configuring prebuilt agents over building custom ones when the requirement matches.
  • User-grounded retrieval respects its configured identity; check custom tools separately and fix excessive source access.
  • Ground answers in few, trusted knowledge sources.
  • Combine ERP data and documents through supported knowledge or tools; justify any replication and validate identities and freshness.
  • Check release status (generally available or preview) of a feature before recommending it for production.

Sources