In plain words
Technical architecture means deciding where each piece of work lives before anyone writes code. Should a rule run in the browser or on the server? During the save or after it? In a flow, in a plug-in or in an agent?
Think of building a house. You decide where the plumbing and wiring go before the walls go up. Moving them later is expensive. The same is true for business logic.
For a developer, architecture is also about restraint. Every plug-in, script and function you add must be tested, deployed, monitored and maintained for years. A good architect writes the least code that meets the requirement, and puts each piece where it is cheapest to run and easiest to trust.
Why it matters
The Campus Help Desk grew fast. A rule written as a client script only runs on one form, so tickets created from the canvas app skip it. A heavy SLA check written as a synchronous plug-in makes every save slow. A due date calculated by an AI prompt changes from one run to the next. Each is a wrong architecture choice, not a coding bug. AB-400 tests these choices heavily.
How it works
Step 1: can out-of-the-box features meet the need? Check business rules, formula columns, views, security roles and standard connectors first. Code costs more to build, test and maintain.
Step 2: choose where logic runs.
| Option | Runs | Best for | Limits |
|---|---|---|---|
| Business rule | Form, and server for table-scope rules | Simple show, hide, require, set value | No external calls, simple conditions |
| Client script | Browser, on the form | Instant form feedback, notifications | Skipped by imports, API calls and canvas apps |
| Synchronous plug-in | Server, inside the transaction | Validation and data changes for every channel | Must be fast; slows every save |
| Asynchronous plug-in | Server, after the save | Follow-up work, external calls | User does not see the result at once |
| Azure Function | Azure | Long-running, scheduled or event-driven jobs | More infrastructure to run |
| Cloud flow | Power Automate | Notifications, approvals, connector work | Not for blocking saves |
| Copilot Studio agent | Copilot Studio | Conversations, knowledge, reasoning | Non-deterministic output |
Step 3: choose where data lives.
- Standard tables for normal business data with full Dataverse features.
- Virtual tables when data must stay in another system but appear in Dataverse.
- Elastic tables for very high volume, fast-changing data such as logs and sensor readings.
- Connectors when an app or flow just needs to call a system, without a table.
Step 4: authentication and authorization. Authentication proves who you are, usually with Microsoft Entra ID. Authorization decides what you may do. In Dataverse that is security roles, business units, teams and row sharing. Your code runs under a user or an app identity, and it must respect these rules. For services, prefer a service principal or managed identity over stored passwords.
Step 5: governance. Managed environments add admin controls, and data policies decide which connectors can be used together. A design that needs a blocked connector will fail in production, so check policies early.
Step 6: deterministic or not. A plug-in always gives the same answer. An AI prompt or agent may not. Keep rules, money and deadlines deterministic. Use AI where judgement helps, such as suggesting a category.
Step 7: choose the user experience.
- Generative pages: a model-driven page built from a natural-language description.
- PCF components: reusable custom controls on forms, views and canvas apps.
- Web resources: JavaScript, HTML or images stored in Dataverse, used by forms and commands.
- Code apps: a full custom web app, such as React and TypeScript, hosted on Power Platform.
- Interactive agents and MCP app widgets: UI surfaced inside agent conversations.
Step 8: which agent platform. Copilot Studio is low-code, fast and close to Power Platform. Microsoft Foundry is code-first, for custom models, orchestration and deep engineering control. The two can connect.
Example: Campus Help Desk
The team gives you five requirements. Here is the design.
- Priority from keywords on every new ticket. Synchronous plug-in on Create, PreOperation stage. It runs for the canvas app, the staff app and imports.
- Warn staff on the form when a category has many open tickets. Client script on the Category change event, using
Xrm.WebApi.retrieveMultipleRecords. - Nightly SLA check. Azure Function with a timer trigger, signing in with a managed identity.
- Email the student when a ticket closes. Cloud flow on the Dataverse trigger with a filter on Status.
- Students ask how-to questions. The Help Desk Assistant agent in Copilot Studio.
Student records stay in the Campus Directory, so you plan a custom connector to its API rather than copying the data. Every part lives in the Campus Help Desk solution with the chd prefix.
Common mistakes
- Coding first. A business rule or formula column is often enough.
- Using a client script for validation that must apply to every channel.
- Putting slow work in a synchronous plug-in, so every save waits for an external API.
- Trusting AI for fixed rules such as deadlines or prices.
- Ignoring data policies until deployment, when a connector turns out to be blocked.
How the exam asks about it
- “Regardless of how the record is created”, “must prevent the save” → synchronous plug-in.
- “Without delaying the user”, “long-running”, “nightly” → asynchronous plug-in or Azure Function.
- “Data must remain in the external system” → virtual table or connector. “Millions of rows, high throughput” → elastic table.
- “Same result every time” → deterministic logic, not a prompt or agent.