Automation
Part of CRM integrations
Monitoring failed CRM updates
Find failed and missing CRM integration updates with run history, reconciliation, owned exceptions and safe replay checks.
Monitor whether an integration ran and whether the intended business update arrived. A failed-run alert can reveal an automation error, but it cannot reveal an enquiry whose trigger never fired or prove that operations accepted a request. Compare source events with destination states and give each exception an owner.
Define the expected result
For each important transfer, specify the source event, destination record, expected state and a time for checking it. Choose that time according to the consequence of delay.
Keep a source reference, attempt time, error or rejection reason, current destination state and responsible person in the exception record where available. An alert can point an authorised reviewer to the customer record without copying its full contents into a widely visible message.
Use run history as one signal
Power Automate records run history and error details. Per-run failure alerts are sent when the system identifies a known issue with a specific fix; if it cannot identify a specific fix, no per-run alert email is sent. After an alert is sent for a flow, a 28-day cooldown applies before another per-run alert can be sent for that flow.
The Power Platform admin centre's Monitor experience can track all failures across flows and environments, including failures that don't generate an email.
HubSpot workflow history can show an enrolled record's path and individual action success or failure on the documented Professional and Enterprise subscriptions.
Power Automate Run History & Alert Rules
- Per-run failure alert cooldown
- 28 days
- Alerts sent on known issues with fix
- Yes
- No alert for unknown issues
- True
- Monitor experience available in Power Platform Admin Centre
- Yes
HubSpot Workflow History Access
- Professional Subscription
- Workflow path and action success/failure visible
- Enterprise Subscription
- Full workflow history and detailed action tracking
Triage before replay
| Exception | First check | Next decision |
|---|---|---|
| Bad or missing input | Inspect the source and rejection | Correct the data, then retry if appropriate |
| Access or connection failure | Inspect the connection and effective rights | Restore access, then reconcile |
| Temporary service or rate limit | Inspect the connector's retry state | Wait or retry according to its behaviour |
| Destination may have accepted the request | Search by source reference | Link the existing result before replay |
| No run exists | Compare source events with trigger history | Repair the trigger or route the work manually |
These are investigation prompts, not platform error categories. Before retrying, confirm that the input is still valid.
Reconcile and close exceptions
Compare eligible source events with accepted destination records at an interval appropriate to the business. Keep an individual exception list so a named person can resolve each gap. Close an exception after checking the receiving state, recording whether the item was repaired, handled manually or intentionally rejected.
Before wider use, check how the process signals an invalid field, a lost connection, a repeated event and a receiving-system rejection in a safe test setting.
