Design automations, code app interfaces, and custom agents
Unit 3 leaves you with a custom connector to the depot system, and an MCP server that exposes Dataverse to AI agents. It also leaves you with a set of inbound and outbound integration patterns connecting the two. This unit puts those connection points to work.
You design the automation that carries a request from approval to fulfillment, and a purpose-built interface for the coordinator who oversees that process. You also design a conversational agent that gives employees and coordinators a natural-language way into the whole solution.
Choose between a cloud flow and an agent flow for approval and fulfillment
A Power Automate cloud flow is a trigger paired with a sequence of actions, built with one of three trigger types: automated, which fires in response to an event; instant, which starts when someone selects a button; or scheduled, which runs on a recurring timer. That shape makes a cloud flow well suited to deterministic, event-driven backend processes.
This is work that needs to happen the same way every time a condition in the data is met, with no conversation involved.
For the equipment-provisioning solution, a cloud flow is the natural home for the approval step itself. When a Request record moves to "approved," an automated trigger starts the flow. The flow then calls the depot connector's "reserve device" operation from the previous unit, and notifies the coordinator that the device is on hold. Nobody has to ask for that sequence to happen. The data change is the trigger, and the flow runs the same way every time.
A Copilot Studio agent flow is also an automated sequence of actions triggered by events or conditions. But it's designed and invoked from within an agent's conversational context, helping an agent complete multistep backend work as part of a conversation. Microsoft documentation uses Copilot Studio workflows as the umbrella term for this capability.
An agent flow is how a workflow appears in the standard harness, the default authoring experience in Copilot Studio. The actions look similar to a cloud flow's, connectors, conditions, loops, but the entry point is different: something a person said to an agent, not a change in a table.
Consider an employee who tells the agent, "my request got rejected, please resubmit it with a different device model." Completing that request takes several backend steps: updating the original record, checking eligibility again, and placing a new reservation. But the trigger for all of it is a conversational exchange, not a database event.
An agent flow is the better fit here. An agent invokes it from inside that conversation, and it hands its result back to the agent to relay to the employee.
The decision comes down to where the trigger originates. Use a cloud flow when the trigger is a data or event condition that exists outside any conversation. Use an agent flow when a conversational turn needs to invoke the multistep action.
Decide when a code app replaces a maker-built interface
Power Apps code apps let a professional developer build and run a custom business web app from a code-first IDE, such as Visual Studio Code. The app still runs on the managed Power Platform. That means the developer writes in a framework of their choice. But the app benefits from Dataverse authentication, application lifecycle management, and the same governance policies as any other app on the platform, such as data loss prevention and sharing limits.
However, shared access signature (SAS) IP Binding and Firewall environment settings don't apply to code apps, because their compiled assets are served from a public endpoint. If location-based access restriction is required, confirm the approved Conditional Access approach with the identity or security owner. Document the code-app limitation and escalate any tenant-policy change. A code app occupies the middle ground between a maker-built canvas or model-driven app and a fully custom web app built entirely outside the platform.
The coordinator's triage dashboard started as a generative page in unit 2, and that first draft is a reasonable place to start. But as the coordinator's needs grow, the dashboard starts asking for things a maker-built page can't express. Examples include custom visualizations that plot allowance usage against request volume across every employee, or interaction patterns such as a drag-and-drop reassignment view.
At that point, a code app lets a developer take full code-first control of the interface. It keeps running on the same managed Dataverse platform as the rest of the solution, with the same authentication and governance the coordinator already relies on.
That's the signal to watch for: choose a code app when the interface's complexity or custom logic exceeds what a maker-built app reasonably expresses, and when a professional developer takes ownership of that interface going forward. Short of that threshold, refining the generative page remains the lower-effort path.
Learn more about Power Apps code apps.
Design a custom agent that composes what you already built
Copilot Studio agents extend their capabilities through custom actions, connectors, flows, and custom APIs that let the agent act on external systems. They also extend through knowledge sources that let the agent ground its answers in your data. A Copilot Studio agent can also call an agent built elsewhere, such as in Microsoft Foundry, when that capability already exists outside Power Platform.
The Dataverse MCP server you design in unit 3 is one more option alongside these: instead of a fixed action for every possible question, it lets the agent query Dataverse flexibly and answer things you never had to predefine.
Put those pieces together, and a custom agent for this solution starts to take shape as a composition, not a new build:
- An employee asks about the status of their request, and the agent answers by querying through the MCP server, the same grounding you design in unit 3 for open-ended questions.
- The employee asks whether they're eligible for a new device. The agent invokes the
CheckEquipmentEligibilitycustom API from unit 2 as a custom action. That's the same reusable contract the request form and a cloud flow already call. - The employee asks the agent to kick off a new request. The agent invokes the cloud flow or agent flow you design earlier in this unit, to carry out the multistep work.
Notice what's missing from that list: nowhere does the agent reimplement eligibility logic, reservation logic, or query logic of its own. A well-designed agent composes the custom API, MCP server, and flow you already designed rather than rebuilding that logic inside the agent itself.
That principle matters beyond this one solution. Every time you're tempted to write a new rule or a new query directly into an agent's instructions, stop. Ask whether a component you already designed, or should design, could carry that logic instead. That leaves the agent to orchestrate, rather than implement.
Synthesis prompt: Suppose a future request asks the agent to check whether a specific depot location has a device in stock. Would you add that logic directly into the agent's instructions, or expose it through one of the components from this module? Which one, and why?
Match each orchestration pattern to the job it's built for
Four patterns, each composing the components earlier units design rather than introducing a new primitive. Use this table to transfer the decision points from this unit to a new scenario.
| Pattern | Best for | What it composes |
|---|---|---|
| Cloud flow | A deterministic, event-driven process triggered by a data or schedule condition outside any conversation | The depot connector's reserve operation, notification actions |
| Agent flow | Multistep backend work that an agent invokes from inside a conversational turn | The same kind of connector and data actions, triggered from a conversation instead of an event |
| Code app | A coordinator or developer-owned interface whose complexity exceeds what a maker-built app expresses | Dataverse data, Power Platform connectors, the solution's existing authentication and governance |
| Custom agent | A conversational surface for employees and coordinators to query status, check eligibility, and start requests | The MCP server, the CheckEquipmentEligibility custom API, and the cloud or agent flow |
Automation, interface, and agent now turn the connectors and integrations from the previous unit into a working process. With the solution's pieces orchestrated end to end, the next unit turns to how you monitor that running process and alert the coordinator when something in it needs attention.