Aglet

Prioritize stale notification links with a useful recovery path

Stale links matter when a person arrives ready to act and receives a dead end or an explanation that no longer matches the resource. Compare current-state recovery with route repair. A parent list or status view may restore orientation without recreating the old page.

Decide where the work belongs

  1. Name the blocked task

    Describe the action the notification promised and what the person sees now. Compare moved, changed, archived, and permission-limited targets. Keep an ordinary expired link separate from a stale link that still needs an action.

  2. Compare recovery scopes

    Set current detail, parent list, status explanation, search return, and generic error beside one another. Consider role and context. Prefer a destination that preserves the resource identity and states what changed.

  3. Choose a bounded fix

    Record resource type, age or state boundary, owner, and revisit evidence. Decide whether to change fallback copy, route, identifier handling, or action availability. Preserve a current target control for evaluation.

What to carry forward

Prioritize stale-link work where a notification-driven action becomes a dead end and current context can still orient the person. The decision should name fallback scope and state. If the link is intentionally no longer actionable but clearly explained, queue copy only.

Technical background: Apple 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