Integration & Automation Blueprints

Connecting the dots

Cloud flow design patterns

Power Automate cloud flows are the automation backbone of Power Platform. Good flow design follows these patterns:

Trigger selection

Trigger Type	When to Use	Key Consideration
Dataverse — When a row is added	React to new records	Filter expression to limit which records trigger the flow
Dataverse — When a row is modified	React to field changes	Select specific columns to avoid triggering on every edit
Scheduled	Periodic batch processing	Consider time zones and business hours
HTTP request	External system calls into Power Automate	Secure with authentication (not just URL obscurity)
Manual	User-initiated actions	Useful for on-demand reports or approvals

Flow structure best practices

• Keep flows small and focused — one flow, one job. Don’t build a 200-step monster.
• Use child flows for reusable logic (e.g., “send notification” used in 5 parent flows)
• Scope actions into groups — use Scope actions for try/catch patterns
• Filter triggers early — don’t trigger on every record change, then filter inside the flow
• Use environment variables for configurable values (email addresses, URLs, thresholds)

💡 Scenario: Amara designs an order processing flow

Amara is designing an order processing automation for a healthcare supplies client:

1. Trigger: When an Order record status changes to “Submitted” in Dataverse
2. Validation child flow: Check stock availability (calls inventory system via custom connector)
3. Branching: If stock available → approve and create shipment. If not → notify procurement team.
4. Error handling: Scope wraps the entire flow. On failure, logs the error to a Dataverse “Integration Log” table and sends an alert to the IT team.
5. Security: Uses a service principal connection (not Amara’s personal account) so the flow keeps running after she leaves the project.

This design follows all the best practices: focused trigger, child flows, error handling, and service principal identity.

Dataverse + Azure integration patterns

When Power Platform needs to communicate with Azure services (or vice versa), the choice of pattern depends on latency requirements, data volume, and reliability needs.

Integration patterns — the exam tests whether you choose the right one for each scenario

Pattern	Direction	Timing	Azure Service	Best For
Webhook	Dataverse → External	Near real-time	Any HTTP endpoint	Simple event notification to external systems
Azure Service Bus	Dataverse → Azure	Async (queued)	Service Bus	Guaranteed delivery, decoupled processing, high volume
Azure Event Hub	Dataverse → Azure	Async (streaming)	Event Hub	Telemetry, analytics, massive event streams
Azure Functions (HTTP)	Both directions	Sync or async	Azure Functions	Custom processing, API endpoints, compute-heavy logic
Custom connector	Power Platform → External	Sync (per request)	Any REST API	User-initiated interactions with external APIs
Virtual table	External → Dataverse	Real-time (read)	OData provider	Display external data as Dataverse tables without copying

Sync vs async: the critical decision

Factor	Synchronous	Asynchronous
User experience	User waits for response	User continues working
Error handling	Immediate feedback	Retry logic, dead-letter queues
Reliability	Fails if the target is down	Queued — retries when target recovers
Use case	Credit check before order save	Generate report and email when ready
Dataverse example	Pre-operation plug-in calling Azure Function	Service Bus message triggering Azure Function

💡 Exam tip: When to use Service Bus vs Event Hub

This is a frequent exam question. The key difference:

• Service Bus = message queue. Messages are consumed once, order matters, guaranteed delivery. Think “work orders” — each message is processed by one consumer.
• Event Hub = event stream. Events can be consumed by multiple readers, massive throughput, no guaranteed order. Think “telemetry” — many systems reading the same stream.

Rule of thumb: if you need guaranteed, ordered, once-only processing → Service Bus. If you need high-throughput streaming with multiple consumers → Event Hub.

Designing for failure

Every integration will fail eventually. The design question is: what happens when it does?

Retry patterns:

• Exponential backoff — wait longer between each retry (1s, 2s, 4s, 8s…)
• Circuit breaker — stop calling a failing service after N failures, wait, then try again
• Dead-letter queue — if a message cannot be processed after all retries, move it to a separate queue for manual review

Idempotency:

• Design every integration endpoint so calling it twice with the same data produces the same result
• Use alternate keys or business identifiers to detect duplicates
• The UpsertRequest pattern (covered in Domain 6) is inherently idempotent

Question

What is the difference between a webhook and an Azure Service Bus integration from Dataverse?

Click or press Enter to reveal answer

Answer

A webhook sends an HTTP POST to an endpoint when a Dataverse event occurs — simple but unreliable (if the endpoint is down, the event is lost). Service Bus publishes messages to a queue — guaranteed delivery, retry support, and the message persists even if the consumer is temporarily down.

Click to flip back

Question

When should you use a child flow in Power Automate?

Click or press Enter to reveal answer

Answer

Use child flows for reusable logic that appears in multiple parent flows — like 'send a formatted notification email' or 'log an integration event'. Child flows accept input parameters, execute their logic, and return output to the parent. They keep parent flows clean and make updates easier (change once, applies everywhere).

Click to flip back

Question

Why should cloud flows use service principal connections instead of user connections?

Click or press Enter to reveal answer

Answer

A user connection is tied to a specific person's identity. If that person leaves the organisation or their license is removed, every flow using their connection breaks. A service principal (application user) is not tied to a person — it persists regardless of employee changes and is the recommended identity for production flows.

Click to flip back

Knowledge Check

A logistics company needs to send order data from Dataverse to their warehouse management system every time an order is approved. The warehouse system occasionally goes offline for maintenance. What integration pattern should you recommend?

AA webhook from Dataverse to the warehouse system's APIBA Power Automate flow that calls the warehouse API directly via HTTP actionCA Dataverse event published to Azure Service Bus, with the warehouse system consuming from the queueDA virtual table linking the warehouse system to Dataverse

Check Answer

Knowledge Check

Amara is designing a flow that runs when a patient record is created in Dataverse. The flow must: (1) validate the patient's insurance, (2) create a case in the billing system, and (3) send a welcome email. Steps 1 and 2 can fail independently. What design pattern should she use?

AA single sequential flow with all three steps in orderBThree separate flows, each triggered by the same Dataverse eventCOne flow with parallel branches for steps 1-2, followed by step 3 in a Scope with error handlingDA parent flow that calls three child flows sequentially

Check Answer

🎬 Video coming soon

Next up: Environment Setup & Security Troubleshooting — configuring development environments and troubleshooting security issues.