What's changed: Created PL-400 Chapter 4 (domain: Extend the platform, part 2): custom connectors (Open API definition, auth OAuth/API key/Basic, policy templates, Azure Function, data transformation), platform APIs and Azure Functions (Dataverse Web API OData, Organization service .NET SDK, throttling/retry, OAuth, optimistic concurrency/ExecuteMultiple, Azure Functions long-running/triggers/managed identity), and Power Automate cloud flows (Dataverse connector, expressions, Azure Key Vault, error handling run after, trigger filter/retry, child flows, Entra ID service principal).
4.3Power Automate cloud flows
Understand the Dataverse connector, complex expressions, Azure Key Vault, error handling, trigger filter/retry, child flows, and Entra ID service principals.
Power Automate cloud flows handle low-code automation/integration. Developers build in reliability, reuse, and secret management.
4.3.1Dataverse connector, expressions, secrets
Build flows with the Dataverse connector triggers (row created/updated) and actions (get/update rows). Compute dynamic values with expressions. Retrieve secrets from Azure Key Vault (e.g., API keys) instead of hardcoding them in the flow.
4.3.2Reliability and reuse
Add error handling (scopes and "run after" configuring failure-path actions) for failures. Harden triggers with a trigger filter (conditions to avoid unneeded runs) and a retry policy. Extract shared logic into child flows for reuse across flows. Run unattended via a Microsoft Entra ID service principal, not a personal account.
Cues: "trigger on row create/update" = Dataverse connector trigger. "compute dynamic values" = expressions. "secure secret retrieval" = Azure Key Vault. "failure-path branching" = scope + run after. "avoid unneeded runs" = trigger filter. "reuse shared logic" = child flows. "unattended run" = Entra ID service principal.
Watch the mix-ups: (1) Get secrets from Key Vault, do not hardcode in the flow (environment variables are not for secrets). (2) Trigger filter (start condition) vs retry. (3) Child flow (reuse) vs parent flow. (4) Unattended runs use a service principal, not a personal account. (5) Without run after, failures are swallowed.
4.3.3Section summary
- Dataverse connector triggers/actions; expressions for dynamic values; secrets in Key Vault
- Error handling (scope + run after); trigger filter/retry for robustness
- Child flows for reuse; unattended via Entra ID service principal
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. In a cloud flow, you want to securely retrieve secrets like API keys, avoiding hardcoding. Best?
Q2. You want to extract shared logic for reuse across multiple flows. Best?
Q3. When an action fails in a flow, you want to run specific follow-up (notify/rollback). Best configuration?
Q4. To avoid unneeded flow runs, you want to run only when a condition is met at trigger time. Best?
Q5. You want to run a cloud flow unattended without depending on a personal account. 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.