Solution Architecture: What Goes Where

Where should your logic live?

The OOB-first principle

Every Power Platform architecture should start with one question: can we do this without custom code?

Microsoft’s platform provides hundreds of features that handle common business scenarios. Writing custom code when a configuration option exists creates technical debt, increases maintenance burden, and complicates upgrades.

Requirement	OOB Solution	Why Not Code?
Make a field required when status = Active	Business rule	No deployment, no testing, visible to makers
Calculate total = quantity x price	Calculated column	Auto-updates, no runtime cost
Send email when a record is created	Power Automate	Visual flow, easy to modify, no C# needed
Auto-number new records	Auto-number column	Built-in, no plug-in needed
Restrict field visibility by security role	Field-level security profile or form tabs with role-based visibility	Business rules react to data values, NOT user roles — use security features for role-based access

💡 Exam tip: The 'simplest approach' trap

When the exam says “which approach should you recommend?”, start from the simplest option and work up. The correct answer is almost always the least complex solution that fully meets the requirements. A plug-in is wrong if a business rule can do it. A cloud flow is wrong if a calculated column handles it.

But watch for the reverse trap: if the requirement includes “must run synchronously before the record is saved” — a cloud flow cannot do that. That needs a plug-in.

Where to put business logic

This is the core architectural decision for PL-400. Every piece of logic has a “right home” based on when it runs, what it needs access to, and how it should behave.

Business logic placement matrix — the exam expects you to pick the right row

Factor	Business Rules	Client Script (JS)	Power Automate	Plug-in (C#)	Azure Function
Runs on	Server + client	Client (browser)	Cloud (async by default)	Server (Dataverse)	Azure cloud
Language	No-code (UI)	JavaScript	Low-code (designer)	C#	C#, Python, JS, etc.
Timing	Real-time (form)	Real-time (form)	Near real-time or scheduled	Sync or async (configurable)	Triggered or scheduled
Can block save?	Yes (validation)	Yes (OnSave cancel)	No — runs after commit	Yes (pre-validation, pre-operation)	No — external to Dataverse
Access to external APIs?	No	Yes (with CORS)	Yes (connectors)	Limited (sandboxed)	Yes (full network access)
Runs on mobile?	Yes	Model-driven only	Yes (background)	Yes (server-side)	Yes (server-side)
Best for	Simple field validation	Form UX logic	Notifications, approvals	Data integrity, complex validation	Heavy compute, external systems

💡 Scenario: Amara's business logic decision

Amara Obi is a consultant at Pinnacle Consulting, implementing a claims processing system for a healthcare client. The client has three requirements:

1. When a claim amount exceeds $10,000, require a manager approval field — This is a field visibility/requirement rule. A business rule handles it perfectly.
2. When a claim is submitted, validate against an external fraud-detection API before saving — Must run before save and call an external service. Sandbox plug-ins CAN make outbound HTTPS calls, but for reliability and timeout safety, the best approach is a synchronous plug-in that calls an Azure Function, which calls the fraud API.
3. After approval, generate a PDF and email it to the claimant — Happens after the main transaction. A Power Automate cloud flow is ideal — it runs asynchronously and has PDF and email connectors.

The exam loves scenarios like this because each requirement maps to a different approach.

Choosing the right table type

Dataverse offers multiple table types, each optimised for different scenarios.

Table type selection — the exam tests whether you know when each type fits

Feature	Standard Table	Virtual Table	Elastic Table
Data storage	Dataverse (SQL)	External system (read at runtime)	Azure Cosmos DB (behind Dataverse)
CRUD support	Full (create, read, update, delete)	Depends on provider (read-only by default; some providers support write)	Full CRUD
Search	Dataverse search, views, FetchXML	No Dataverse search, no auditing, no change tracking	Dataverse search supported, but lacks some features (access teams, table sharing, alternate keys)
Security	Full Dataverse security (roles, teams, BUs, sharing)	Organisation-owned only — no user/team ownership	Dataverse security model with ownership, but lacks access teams and table sharing
Scale	Millions of rows (with indexes)	Depends on external source	Billions of rows (Cosmos DB scale)
Use when	Core business data that needs full platform features	You need to surface external data without copying it	Massive data volumes (IoT, logs, telemetry)
Example	Customer records, orders, cases	SAP data, SQL Server views	Sensor readings, audit logs, device telemetry

When to use connectors instead of tables

Sometimes data should not live in Dataverse at all. If you just need to read or write to an external system during a flow or app session, a connector (standard or custom) may be the better choice.

Use a connector when:

• Data belongs to an external system and should stay there
• You only need the data temporarily during a user session
• The external system has its own security and audit requirements
• Real-time access is more important than cached copies

Use a Dataverse table when:

• Data needs to participate in Dataverse features (security, relationships, views, search)
• Multiple apps and flows need the same data
• You need offline access in model-driven or canvas apps
• Reporting and dashboards require the data in Dataverse

Question

What is the OOB-first principle?

Click or press Enter to reveal answer

Answer

Always check if a business requirement can be met with out-of-the-box Power Platform features (business rules, calculated columns, built-in workflows) before writing custom code. Custom code adds complexity, testing burden, and maintenance cost.

Click to flip back

Question

When should you use a plug-in instead of a cloud flow?

Click or press Enter to reveal answer

Answer

Use a plug-in when logic must run synchronously (before the record is saved), when it must enforce data integrity rules that cannot be bypassed, or when it needs to execute within the Dataverse transaction pipeline. Cloud flows run asynchronously after the transaction commits.

Click to flip back

Question

What is a virtual table in Dataverse?

Click or press Enter to reveal answer

Answer

A virtual table surfaces external data (e.g., from SQL Server or SAP) as if it were a Dataverse table — without copying the data into Dataverse. It appears in views and forms but the data is read from the external source at runtime. Read-only by default.

Click to flip back

Question

When should you choose an elastic table over a standard table?

Click or press Enter to reveal answer

Answer

Choose elastic tables for massive data volumes (billions of rows) like IoT telemetry, sensor readings, or audit logs. Elastic tables use Azure Cosmos DB behind the scenes and scale horizontally, but they lack some standard Dataverse features like search and advanced security.

Click to flip back

Analysing existing architecture

When you join a project with existing Power Platform solutions, your first job is to understand what is already built and where the gaps are.

Architecture review checklist:

1. Solution inventory — What solutions exist? Managed or unmanaged? Who owns them?
2. Component map — Which apps, flows, plug-ins, and custom connectors are in each solution?
3. Data model — What tables exist? How are they related? Any circular references?
4. Security model — What security roles, teams, and business units are configured?
5. Integration points — What external systems connect? Through connectors, APIs, or Azure services?
6. Performance — Any known bottlenecks? Large datasets without proper indexing?

💡 Real-world: Architecture smells to watch for

These common architecture problems show up in exam scenarios:

• Business logic in canvas app formulas that should be in Dataverse (no enforcement server-side)
• Synchronous plug-ins making HTTP calls to external services (blocks the transaction, times out)
• Cloud flows doing row-by-row processing instead of batch operations (slow, throttled)
• Custom connectors without authentication configured (security gap)
• Unmanaged solutions in production (cannot be cleanly updated or removed)

Knowledge Check

Amara is reviewing a client's Power Platform architecture. She finds that a canvas app validates order data by calling an external credit-check API directly from the app using a custom connector. The client wants this validation to be mandatory — no order should be created without passing the credit check. What should Amara recommend?

AKeep the current approach — the canvas app connector call works fineBMove the credit check to a synchronous Dataverse plug-in that calls an Azure Function, which calls the credit APICReplace the connector call with a Power Automate flow triggered on record creationDAdd a business rule to validate the credit check field

Check Answer

Knowledge Check

A client needs to display product inventory data from their SAP system inside a model-driven app. The data must remain in SAP (single source of truth) and does not need to be editable from Power Platform. Which approach should you recommend?

ACreate a standard Dataverse table and sync data from SAP using a scheduled flowBCreate a virtual table backed by a virtual table data provider for SAPCCreate an elastic table to handle the large data volumes from SAPDUse a custom connector in a canvas app embedded in the model-driven app

Check Answer

🎬 Video coming soon

Next up: Security by Design — designing authentication, authorization, and DLP strategies for your Power Platform solutions.