Aglet

Learn from notification fallback and duplicate delivery choices

A fallback lesson should preserve what happened when the preferred channel was unavailable and whether an alternate path helped. Compare later muted, failed, and successful events with the original channel matrix, then improve one review question about visibility, preference, or duplication.

Keep the lesson for the next incident

  1. Keep the channel evidence

    Record event identity, preference, channel, attempt, status, fallback, in-app record, action, copy, and user outcome. State whether delivery or only durable state was observed. This keeps later routing decisions honest.

  2. Compare later failures

    Review muted, denied, delayed, and preferred-success paths after the change. Look for a duplicate cascade or an event that disappears from durable history. Preserve a no-fallback control and a useful alternate path.

  3. Refine one fallback check

    Require future reviews to test preferred, muted, failed, and recovered states, plus duplicate identity and in-app visibility. Assign ownership and revisit date. Define the observation that would show the check preserved important events without overriding choice. Retain the event identity when comparing channel outcomes.

What to carry forward

The learning record connects one fallback decision to later channel evidence and a repeatable visibility-and-duplication review. Stop when a future reviewer can apply the visibility check to another event. Carry forward uncertainty where platform permission or external delivery remains unobservable.

Technical background: Android developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow