What's changed: Created PL-400 Chapter 1 (domains: Create a technical design + Build solutions/ALM): technical architecture design (logic placement business rule/plug-in/Power Automate/client scripting, table types standard/virtual/elastic, DLP/security roles/teams/business units/row sharing), solution component design (canvas component/PCF code component, custom connectors, Power Fx/plug-in/custom API, integrations), and ALM (managed/unmanaged, solution layers, environment variables, Pipelines, Build Tools CI/CD).
1.1Design the technical architecture
Understand where to place business logic (business rule / plug-in / Power Automate / client scripting), table types (standard / virtual / elastic), and authn/authz and security (DLP / security roles / teams / business units / row sharing).
Strong Power Platform development starts with deciding where to place logic. Choose the right extension point by requirement, execution location, and timing.
1.1.1Business-logic placement
Business rules do no-code form visibility/required/simple validation; client scripting (JavaScript) handles immediate UX on the form (dynamic display). A plug-in runs business logic server-side, synchronously/asynchronously on Dataverse events (create/update, etc.)—core to data integrity. Power Automate (cloud flows) suit cloud automation/integration (approvals, notifications, connecting services). If out-of-the-box suffices, avoid custom code.
1.1.2Table types
A standard table stores data in Dataverse. A virtual table represents an external data source virtually without copying into Dataverse (reads external in real time); an elastic table is a NoSQL-style table (Cosmos DB-based) for large volume/high throughput/variable schema. Choose by requirement (store/external/scale). For integration-centric needs, a connector is an option.
1.1.3Authn/authz and security
Grant access via security roles (sets of privileges), scoped by teams (user groups) and business units (org hierarchy). Share individual records exceptionally via row sharing. Org-wide, data loss prevention (DLP) policies restrict connector usage to prevent mixing business/non-business data. Assign components least privilege.
Cues: "no-code form validation/display" = business rule. "immediate form UX (JS)" = client scripting. "server-side on Dataverse events" = plug-in. "cloud automation/integration" = Power Automate. "represent external virtually" = virtual table. "large/variable schema" = elastic table. "restrict connector usage" = DLP. "set of privileges" = security role.
Watch the mix-ups: (1) Plug-in (server/Dataverse events) vs client scripting (client/form UX). (2) Business rules (no-code, simple) are not a plug-in substitute. (3) Virtual (external, no copy) vs standard (stored in Dataverse) vs elastic (large NoSQL). (4) DLP (connector control) vs security roles (record permissions) are different layers.
1.1.4Section summary
- Logic placement = business rule (simple) / client scripting (UX) / plug-in (server events) / Power Automate (cloud automation)
- Tables = standard (store) / virtual (external virtual) / elastic (large NoSQL) by requirement
- Security = roles/teams/business units/row sharing; org-wide DLP controls connectors
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to run complex server-side business logic on Dataverse create/update events. Best extension point?
Q2. Without code, you want to show/hide fields, set required, and simple validation on a form. Best?
Q3. You want to reference external data in real time as a table without copying into Dataverse. Best table type?
Q4. For very large data, variable schema, and high-throughput writes, which table type is best?
Q5. Org-wide, you want to classify and restrict connector usage (business/non-business) to prevent data leakage. Best?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.