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?