Check maintenance and onboarding notification delivery
Use per-recipient delivery and communication history to verify notification outcomes, especially after a workflow change.
Before you start
Use per-recipient delivery and communication history to verify notification outcomes, especially after a workflow change.
Follow these steps
- Open the exact maintenance request or onboarding case.
- Check the current native status and the intended tenant, landlord, supplier or staff relationship.
- Inspect available communication/delivery history and distinguish successful, failed and suppressed duplicate attempts.
- Confirm the recipient identity and active contact before a supported retry.
- Use the supported resend or workflow action only after checking whether an earlier send already succeeded.
Check it worked
The record history shows the intended event and individual recipient outcomes.
If something does not look right
The current merged release includes maintenance landlord recipients, staff in-app alerts, onboarding communication rows and duplicate suppression. A suppressed repeat is not a new delivery, and a failed send needs its own review.
Questions and answers
Do all status updates email every stakeholder?
Recipients depend on the native workflow, active relationships, event and permissions. Review the recorded recipients rather than assuming all roles were notified.
Does a successful send prove inbox receipt?
No. It records the application/transport outcome; inbox placement and reading are separate evidence.
How does this relate to Zero-Chase?
Native workflow notifications and Flow automation are separate mechanisms. Review both to avoid unintended overlapping follow-ups.