Dynamics 365 Power Platform Integration UAT: What to Test Before Release

Dynamics 365 integrations are business processes split across systems. An opportunity won in CRM may create a finance record, update a customer platform, start fulfilment, and change a forecast. A field service work order may need inventory, scheduling, billing, and customer communication. The flow is only successful when the full chain reaches the expected business outcome.

Integration UAT must test the event, payload, permissions, timing, downstream response, monitoring, and recovery—not just whether a connector can authenticate. It should also use the record conditions that make production different from a clean demo environment.

1. Map each integration as an observable business journey

For each critical flow, document the source event, trigger conditions, transformations, actions, downstream records, user notifications, monitoring location, and recovery owner. This gives testers a way to prove the outcome rather than merely inspect a successful run.

• —CRM opportunity to ERP, finance, quoting, fulfilment, or revenue-recognition records.
• —Customer, account, contact, product, price, and order synchronisation between Dataverse and connected systems.
• —Power Apps submissions that create or update Dynamics records with role-specific fields and approvals.
• —Field Service work orders that trigger inventory, scheduling, billing, or customer communications.
• —Alerts, dashboards, queues, and manual processes that support a failed or delayed integration.

2. Test payloads that break assumptions

Flows often pass with a simple record and fail when a field is blank, a relationship is missing, a value contains special characters, or a transaction uses a different currency or legal entity.

• —Missing optional and required fields, null relationships, inactive owners, and invalid foreign keys.
• —Special characters, long text, multiple currencies, time zones, dates, decimal rounding, and multi-line addresses.
• —New, updated, reopened, cancelled, duplicated, and deleted records where the flow has different expected behaviour.
• —High-volume batches, concurrent updates, duplicate events, connector throttling, and delayed downstream responses.

3. Validate identity and connector permissions

The flow may run as the connection owner, a service account, or the initiating user. Test the exact identity model used in production and confirm that permissions are neither too broad nor too narrow.

• —Create and update permissions for every Dataverse table and field the flow touches.
• —Connection references, environment variables, service accounts, application users, and secret rotation behaviour.
• —A user who can trigger the flow but must not read or edit the downstream record.
• —Disabled users, expired credentials, changed ownership, and a connector outage with clear operational alerts.

4. Test retries, duplicates, and ordering

A temporary failure should not become duplicate orders, duplicate customers, or conflicting updates. Force a timeout or rejection and verify how the platform retries, records, and reconciles the event.

• —Retry after a timeout without creating a second downstream record.
• —Receive duplicate or out-of-order messages and confirm idempotency and conflict handling.
• —Partially complete a multi-step flow and verify the next run can resume or safely compensate.
• —Reconcile source and target counts, identifiers, statuses, timestamps, and error queues after recovery.

5. Prove monitoring and business recovery

Every critical integration needs an operational answer to three questions: how will the team know it failed, who owns the failure, and how can they recover without losing the business event?

“An integration is ready when a business event reaches every required system—and when a failed event becomes visible, owned, and recoverable before the business feels the gap.”