Adding an agent to Power Apps is a product-lifecycle and trust-boundary choice, not a generic instruction to embed chat. A canvas app, a model-driven experience and a separately hosted agent can expose different user context and authenticated connectors. Start with the supported integration path for the current tenant and release; older canvas-app Copilot examples may not apply to new applications. In a fictional approval form, an agent may suggest a category or populate a draft, but the app must validate field rules and a trusted business service must decide whether the signed-in user can save or submit it. When using third-party AB-100 practice questions to evaluate such a design, require the answer to distinguish the user interface, agent invocation, Dataverse authorization and durable transaction result. A generated field value is not proof that an authorized transaction was committed.
Imagine a fictional field-service organization with a canvas app used by technicians and a model-driven app used by dispatchers. Technicians collect equipment condition, photos and repair notes. Dispatchers assign work and approve high-cost parts. The company wants AI assistance for both roles, but the actions, data visibility and supported user experiences are different. The architect must decide where to place the conversation, how to authorize each action, and how to make the solution survive a feature change.
Start from Microsoft’s 2026 canvas Copilot change
Microsoft’s custom Copilot in canvas apps documentation states that, starting February 2, 2026, adding a custom Copilot through that older feature to NEW canvas apps is discontinued. Existing apps using it may continue for a limited time but are not a reliable basis for indefinite new development. Microsoft’s guidance points toward Microsoft 365 Copilot in canvas apps as the recommended direction for natural-language interactions.
Microsoft’s February 2, 2026 restriction concerns adding the older custom Copilot feature to new canvas apps; it does not mean every existing deployment stopped functioning on that date. An older screenshot may therefore show an option unavailable to a new maker while an existing app continues during a limited transition. Existing customers need a separate migration and risk decision: inventory affected screens, dependent connectors, security roles and users; compare a currently supported alternative in the relevant tenant; and plan regression testing and decommissioning before the old experience loses support.
The 2026 release-plan description for Microsoft 365 Copilot in canvas apps identifies public-preview availability in its published table, not blanket general availability for every region and tenant. Feature details, licensing, UI placement and limitations must be checked against the actual environment. An architect should label the preview status rather than promise a production capability based on marketing examples.
Separate canvas apps from model-driven app decisions
Canvas apps are often optimized for a task-specific interface, with explicit navigation and formulas. Model-driven applications derive substantial interface and workflow behavior from Dataverse tables, forms and business rules. Both can use AI-backed services, but the integration point should reflect the user’s job and the supported product experience, not a universal “add AI” step.
The field technician may benefit from a bounded assistant that explains a repair procedure from an authorized manual and prepares a draft service note. Dispatchers may need contextual summary of an active work order plus permitted recommendation of resource allocation. Those are different information needs. A technician’s app must not silently gain the dispatcher’s ability to approve an expensive component merely because the same agent configuration is reused.
Map the primary app action first. Does the user need an answer, a draft, a suggested field value, or an actual transaction? Let the app and trusted services own authoritative data changes, with explicit confirmation or approval where required. A generated suggestion should retain provenance and validation so the receiving application can reject unsupported fields or values.
Use an agent-hosting design that matches the user journey
An assistant might live in Microsoft 365 Copilot, a dedicated Copilot Studio agent, or an app-supported experience, depending on current availability and the intended channel. Microsoft’s Copilot Studio channel guidance describes differences among channel clients and deployment paths. Do not equate having a Direct Line client with gaining all capabilities of a Microsoft 365 Copilot host.
For technicians, repeated switching from the equipment record to a separate conversation may lose important context; an embedded or closely linked experience can help only if that context is passed legitimately. Treat context as a signed or validated reference to an asset and case, not a user-editable query parameter that the agent trusts unconditionally. If a technician has access to one customer site, the assistant must not retrieve another site’s confidential service history.
For dispatchers, the agent may need to explain why a work order appears high priority. It should present relevant observations, documented rules and uncertainty before the dispatcher confirms a reassignment. Some channel clients offer richer message or card support than others, so an approval design cannot depend on a visual button that disappears in another client.
Define the security boundary around Dataverse and connectors
Dataverse row and column protections, app privileges and backend tool access should be reviewed as separate layers. A user who can view a form may not be allowed to invoke every connector action. A service identity with broad permissions is not a safe shortcut around missing end-user authentication. The backend must authorize an operation against the actual user and record even when an AI suggestion appears reasonable.
For the field-service case, an AI tool could retrieve approved maintenance knowledge, read the current work order, or create a proposed visit note. A different tool could submit a parts request for review. A privileged tool that marks a task completed or commits a financial item must check the user’s role, target company and permitted transition. Keeping these tools separate reduces the chance that a prompt manipulates the agent into invoking an unintended operation.
Even when Dataverse grounding and permissions constrain retrieved records, passing a selected screen value to an agent creates a second authorization decision. Check the caller’s delegated identity, app role, connection references and revocation status at the trusted service. A cached agent context must not outlive the caller’s actual authorization.
Treat an AI-drafted form value as untrusted input
Suppose an assistant extracts a serial number from a photo and suggests a warranty category. OCR and language-model output may contain transposition errors, missing characters or a category not recognized by the service system. The application should display the draft, validate its schema and business rules, allow correction, and record who approved the field. It should not silently set a warranty entitlement based on an unverified image.
A robust data contract might return serial_candidate, source_image_reference, extraction_status, needs_confirmation, and reason. The app can require an authoritative lookup before creating the case. If the serial is unreadable, an explicit missing state is more useful than a plausible value filled in to satisfy a required field.
Use negative tests: a QR code attached to the wrong machine, a technician scanning a customer’s confidential document accidentally, a stale work order, a disconnected device and a deliberately crafted instruction embedded in a service note. The agent must not treat retrieved text as authority to call privileged tools or override app validation.
Plan migration for legacy canvas experiences
Before changing an existing app that uses an older custom Copilot integration, create an inventory of screens, agent identities, knowledge sources, connectors, security roles, telemetry, supported tenants and user populations. Capture the currently working behavior and known limitations. The migration plan should include a supported alternative, comparison of capabilities, regression tests and a rollback or parallel-run period where feasible.
Avoid using a simple screenshot comparison as proof of equivalence. An app may retain the appearance of a chat panel while losing per-user authorization, source citations or a backend action. Check the functional contract: can a technician access only appropriate records, can an unresolved job be escalated, and does the agent distinguish suggestion from committed service change?
Because release plans and product roadmaps can change, recheck Microsoft’s current documentation near deployment. A configuration that was supported for existing apps on a given date may later have tighter restrictions. Record the feature’s support state and owner’s migration decision; do not silently relabel a legacy preview as current best practice.
Test the actual app-device-channel combination
A field-service canvas app may run on mobile devices under intermittent network connectivity. The AI component should not claim that it saved a note when the backend never acknowledged it. A failed submission may require local draft retention, explicit retry and deduplication on reconnect. The authoritative service should assign a durable correlation ID and prevent duplicate transactions.
Dispatchers using model-driven apps may work with multiple browser tabs, stale forms and frequent record updates. Test that agent recommendations are based on the intended record version and that conflicts are surfaced rather than overwritten. User behavior varies by device and channel; a passing test in the maker preview is not full acceptance for a field device or real dispatcher shift.
Also measure whether AI helps the actual work: correct draft completeness, rate of human corrections, time to obtain verified service facts, duplicate-case avoidance, and unauthorized-action prevention. Do not count clicks or generated answers as business success if technicians spend more time repairing bad suggestions.
State the supported design decision explicitly
For a new canvas app, use documented current Microsoft 365 Copilot pathways only where tenant availability and business requirements support them; do not prescribe the discontinued new-app custom Copilot feature. For existing legacy apps, keep an explicit support and migration plan. For model-driven and cross-application workflows, make identity, source permissions and trusted service actions separate from generated dialogue.
A Power Apps agent may participate in Dynamics 365 cross-application workflows, but its host determines which screen context is shared, how the user authenticates, and how a proposed edit becomes a trusted business operation. The technician and dispatcher scenario is fictional: no canvas app, model-driven app or Dataverse record was deployed or modified here.