Reusable Power Fx and Handing Off to an Agent
Named formulas, user-defined functions and component libraries — plus creating a Copilot Studio agent from a canvas app, and exactly where that hand-off ends.
Stop repeating yourself
Nadia’s driver app has the same expression pasted into eleven places: work out whether a run counts as delayed. When the business changes the definition of “delayed,” she has eleven edits to make and one she will forget.
Power Fx offers three reuse mechanisms, and the exam expects you to pick between them precisely.
Named formulas versus user-defined functions
This distinction is worth getting exactly right, because it is easy to state backwards.
A named formula is a reusable value. A user-defined function is a reusable value that takes inputs.
”Today’s cutoff time” is a named formula — it is one thing, always the same thing, calculated when needed.
”Is this run delayed?” is a user-defined function — you have to tell it which run, so it needs a parameter.
The one-line version: named formulas have no parameters. Functions do.
The error to avoid
Do not claim that named formulas accept parameters. That is the precise misconception Microsoft’s documentation exists to correct, and it is a natural distractor in an exam question.
The direction is: UDFs are an extension of named formulas that adds parameters. Named formulas are the simpler thing.
| Named formula | User-defined function | |
|---|---|---|
| Takes parameters | No | Yes |
| Returns a value | Yes | Yes |
| Supports behavior formulas | No | Yes |
| Defined on | The App object (App.Formulas) | The App object (App.Formulas) |
| Kite Freight example | CutoffTime — today's dispatch cutoff | IsDelayed(run) — whether a given run is late |
Component libraries
Named formulas and UDFs reuse logic within an app. Component libraries reuse components across apps.
What a component library is for
A component library holds reusable canvas components — a branded header, a depot picker, a signature capture control — that multiple apps can consume.
The reason it matters organisationally: a component defined inside a single app cannot be used by another app. Moving it to a component library is what makes it shareable, and it means an update to the component can be picked up by every consuming app rather than re-implemented in each.
For the exam, the discriminator is scope. If a scenario says “we want the same control in several apps, maintained once,” that is a component library — not a named formula, not a UDF.
| Mechanism | Reuses | Scope | Scenario wording that points here |
|---|---|---|---|
| Named formula | A computed value | Within one app | 'The same calculation appears in several places in this app' |
| User-defined function | A parameterised calculation or behaviour | Within one app | 'The same logic, but applied to different records' |
| Component library | A UI component | Across many apps | 'We want this control in all our apps, maintained once' |
Creating a Copilot Studio agent from a canvas app
This is the objective people over-study, so let us be precise about what it is and where it stops.
What the objective actually covers
The AB-410 study guide bullet is “Create a Copilot Studio agent from a canvas app.” That is the hand-off point — creating the agent, and knowing the prerequisites and constraints.
What happens inside Copilot Studio afterwards — authoring topics, tools, MCP connections, agent ALM, multi-agent orchestration — is AB-620’s exam, not this one.
If you find yourself learning topic trigger phrases, you have crossed the line.
Agent builder in Power Apps lets organisations use the knowledge, logic and actions of an existing app to create agents — so makers can automate processes within the canvas app they already have.
How agent builder actually works
Microsoft’s description is worth reading closely, because it tells you what the inputs are: agent builder uses the app’s metadata and the desired agent goal to generate a step-by-step process, extract knowledge, and identify triggers. Those are then combined with skills extracted from the app.
So you do not hand it a specification. You hand it an app that already works plus a sentence describing the process you want automated, and it infers the rest.
The route in the product: Power Apps → Agents → Create an agent from an app, or from Apps, select the app and choose Create agent from app.
Afterwards, makers “edit, test, and publish it in Microsoft Copilot Studio.” That sentence is the hand-off point the exam cares about.
The prerequisites for agent builder
These are documented, unglamorous, and exactly the kind of thing a scenario question hangs on.
Four things that must be true first
- A tenant administrator has turned on the Publish Copilots with AI features setting in the Power Platform admin center.
- The environment includes a Dataverse database.
- Block unmanaged customizations is disabled for the environment.
- The environment has a current enough Copilot Studio solution version.
Notice the shape here — it is the same shape as row summaries in Domain 1: a maker-facing AI feature with an administrator-controlled prerequisite sitting in front of it. That pattern repeats across this exam, and recognising it is worth more than memorising any single instance.
A note on the older Copilot control
You will still find articles, videos and practice questions about a Copilot control that makers added to canvas apps via Insert → Copilot (preview). It is worth knowing why that advice has dated, so you do not follow it into a dead end.
Why you should not build on it now
Microsoft’s documentation is direct: “Starting February 2, 2026, you can’t add the Copilot control to new canvas apps. Existing apps with this control will remain functional for a limited time but will eventually no longer be supported.”
The stated replacement is Microsoft 365 Copilot in canvas apps, and Microsoft recommends migrating “as soon as it becomes available in your environment.”
The old control’s constraints — Dataverse tables only as a data source, an admin setting to switch it on, and no support in environments using a customer-managed key or Customer Lockbox — still describe existing apps that carry it. They are simply not a build path for anything new.
The examinable objective in this area is creating a Copilot Studio agent from a canvas app, which is the agent builder flow above. If you are memorising Copilot-control prerequisites, you are studying a retired feature.
Kite Freight tidies up
Nadia’s cleanup pass on the driver app:
| Problem | Fix | Why this mechanism |
|---|---|---|
| ”Is this run delayed?” pasted in 11 places | IsDelayed(run) user-defined function | It varies by record, so it needs a parameter |
| Dispatch cutoff time recomputed everywhere | CutoffTime named formula | One value, no parameter needed |
| Depot picker rebuilt in three apps | Move it to a component library | Cross-app reuse, maintained once |
| Ravi wants the app to automate the “chase a delayed run” process | Create an agent from the app (agent builder) | Uses the app’s own metadata and skills, then hands off to Copilot Studio |
The agent turns out to need a few checks before Nadia can promise anything:
- Has a tenant admin turned on Publish Copilots with AI features in the Power Platform admin center? Not yet. Nothing appears until Mei does.
- Does the environment have a Dataverse database? At Kite Freight, yes — Depot Run already lives there.
- Is block unmanaged customizations disabled? Mei confirms it is.
Ravi also asks whether he can just drop the old Copilot control onto a new screen so users can chat with the run data. He cannot — that door closed for new canvas apps on 2 February 2026, and the direction of travel is Microsoft 365 Copilot in canvas apps instead.
Quick recall
Check yourself
Nadia has the same delay-check expression in eleven places in one canvas app. The expression must be evaluated against a different run each time. What is the right reuse mechanism?
Ravi asks Nadia to add the Copilot control to a brand-new canvas app so users can chat with the run data. What should she tell him?
Three Kite Freight apps each contain their own copy of a depot picker control. The business wants one version, updated centrally. What should you recommend?