An invoice agent notices overdue work overnight and prepares twelve reminders. Finance receives a push notification during the morning commute. The mobile experience should let finance understand why the proposal matters and decide whether the proposal deserves review now.
A push notification is an invitation to a saved product decision. The operating system’s permission to display alerts is separate from permission to read invoices or send email.
Choose which proactive mode the product offers
| Mode | Invoice example | Required product behavior |
|---|---|---|
| Notice | Unpaid invoices meet a configured condition | Explain why the finding matters and allow dismissal |
| Prepare | Draft reminders under a standing rule | Save the exact proposal and route review to an owner |
| Act | Send reminders within an explicit standing grant | Enforce current limits and leave a per-invoice receipt |
The mode should be visible in setup and in the result. A rule that prepares drafts should not begin sending because a newly added skill can call an email tool.
Shopify documents Pulse suggesting work from the admin home page, with individual changes approved before applying. The pattern is proactive preparation followed by a decision; the documentation does not establish the mobile push sequence in this guide. Sidekick Pulse
Design the trigger and notification policy together
A reminder finding needs a stable identity, such as a rule ID plus an invoice set and relevant record versions. Duplicate events should update the existing finding instead of creating repeated notifications.
The rule should name the recipient, delivery channel, quiet hours, time zone, and expiration. Notification permissions need a fallback: a durable in-product inbox where the proposal remains discoverable when push is unavailable.
Allow a person to distinguish “not now,” “this finding is expected,” and “stop this rule.” Snoozing changes delivery timing. Dismissing changes the finding’s state. Pausing changes future runs. A single close button should not silently choose among those meanings.
Keep the notification payload small
The notification should carry an opaque proposal ID and a short description appropriate for the device’s lock screen. Do not put customer balances, full messages, or access tokens into the link.
A practical delivery stack can use APNs for Apple devices or Firebase Cloud Messaging for supported clients. FCM distinguishes notification messages handled for display from data messages handled by the application. Notification behavior changes depending on whether the app is in the foreground. FCM message types
The application server owns the proposal record and routing. A messaging provider accepting a payload is not evidence that a person viewed the proposal. The job should remain usable even when delivery is delayed or absent.
Open the exact proposal after checking access
The deep link opens the saved proposal, not a new chat prompt asking the model to reconstruct the work. Authenticate the person, resolve the tenant, check access, then load the current proposal state.
| State when the person opens the link | Mobile result |
|---|---|
| Proposal remains pending and current | Show the reviewed objects, consequences, and decision controls |
| Another reviewer already accepted | Show the decision and current execution receipt |
| An invoice was paid after preparation | Mark the affected item stale; follow the declared refresh policy |
| Proposal expired | Explain expiration and offer fresh preparation |
| Person no longer has access | Show a permitted access message without leaking invoice detail |
| Run partly completed | Show completed effects and remaining work separately |
A notification can arrive after a proposal expires. The server state wins over the text in the notification.
Fit review into a small screen without hiding the consequence
The top of the mobile card should show the job, destination, acting account, scope, and external effect. “Send 12 invoice reminders” is more informative than “Approve tool call.” Expandable rows expose every recipient and message.
Keep the action label specific. A batch that mixes edits and irreversible sends needs to expose both effects. A person should be able to defer to desktop when the details require a larger review surface.
A notification action that executes a consequential write still needs authenticated, current review and execution checks. Opening a proposal is usually the clearer starting point for a complex batch. The approval guide covers exact proposals and stale state.
Return a receipt to every surface
After acceptance, show execution progress under the same job ID. The person may switch devices or close the app; the pending job and final receipt should remain in history.
Use separate statuses for declined, expired, cancelled, executing, partly completed, failed, and unknown. A green tool status cannot tell the person that a provider accepted an email but delivery remains unconfirmed.
The proactive rule guide explains revocation and pause behavior. The runtime guide explains jobs that outlive the viewer.
Measure whether the interruption helped
Track findings created, notifications attempted, observed opens, decisions, checked results, and later corrections using the same finding and job IDs. Distinguish an ignored alert from a dismissed finding and a deliberately paused rule.
Review a sample of ignored findings. Finance may already have handled the invoice, may lack mobile review access, or may find the notification irrelevant. Increasing push volume will not resolve those causes.
Evaluate delayed delivery, duplicate events, expired proposals, two reviewers, revoked access, and disabled push. Successful mobile review means the right person can make an informed decision and find the result later, even when the notification path fails.