# Urgent Is Not Confirmation > Urgent now controls time-sensitive delivery; confirmation asks for a recorded human response. Either can stand alone, and a Ping can carry both when the moment needs both. - Published: 2026-08-23 - Author: PingRoom - Category: Product - Topics: urgent Ping, confirmation Ping, time-sensitive notifications, Ping acknowledgement - Canonical: https://pingroom.io/blog/urgent-is-not-confirmation - Cover image: https://pingroom.io/blog/urgent-is-not-confirmation.webp - Cover description: One Signal Red Ping divides into a path that breaks through barriers and a separate human response loop. Urgency answers one question: **how should this Ping arrive?** Confirmation answers another: **does somebody need to respond?** PingRoom previously bound those choices together. Marking a Ping Urgent raised its delivery priority and opened the acknowledgement lifecycle. Events that needed only one still inherited both. The August 22 source changes separate them. **Urgent Ping** and **Require confirmation** are now independent controls across the mobile app, web composer, server, SDK, CLI, and webhook contract. This is a source-level development update, not a public-release announcement. ## Urgent Controls Delivery An Urgent Ping asks the operating system for time-sensitive delivery without asking a person to take ownership of it. The recipient's device and notification settings remain the final authority over how time-sensitive alerts behave. PingRoom supplies the delivery intent; it does not override the operating system. Urgency does not create an acknowledgement deadline. It does not start an acknowledgement Live Activity. It does not wait for a first response or record who answered. The Ping arrives with higher priority and asks nothing else. Urgent Pings can be used in private and public rooms because urgency changes delivery, not who may respond. ## Confirmation Opens A Lifecycle Confirmation keeps a Ping actionable until an eligible recipient confirms it, the deadline passes, or the event otherwise resolves. Confirmation remains private-room only. The first eligible response wins for the room, and the server records the result. That gives the sender a concrete answer instead of an assumption based on delivery. On iOS 17 and later, the acknowledgement Live Activity now includes a **Confirm** action on the Lock Screen and expanded Dynamic Island. The tap posts the response without opening PingRoom and retires the local Live Activity immediately. The server's end update remains the cross-device source of truth. ![Two Signal Red paths cross one room independently: priority reaches a recipient while confirmation waits for a human tap.](/blog/urgent-is-not-confirmation-1.webp) ## Either, Or Both The split supports three combinations: - **Urgent only** when timing matters but no recorded response is needed. - **Confirmation only** when a person must take responsibility, but normal delivery priority is appropriate. - **Urgent and confirmation** when the Ping must arrive time-sensitively and remain open until someone responds. Neither control silently implies the other. An incident broadcast may need to cut through Focus without making every recipient race to acknowledge. A routine handoff may need one recorded confirmation without interrupting a quiet period. A critical overnight escalation may need both. ## Two One-Shot Controls In the mobile room, the Ping options menu now exposes **Urgent Ping** and **Require confirmation** separately. Each applies to the next quick or custom Ping and clears after that send is accepted. The quick-action grid also shows the difference at a glance. A bolt badge represents urgent delivery. An ACK chip represents either the quick action's saved confirmation policy or the one-shot confirmation setting. Quick Pings can still store a persistent confirmation policy when a specific room action should always require a response. Urgency stays send-time only. A button can remember that **Door checked** needs confirmation without making every use time-sensitive. The web composer follows the same distinction with its own Urgent switch alongside the existing confirmation setting. ## One Contract From App To Automation The API now carries `is_urgent` independently from `requires_ack`. Quick-action triggers, direct agent Pings, and incoming webhooks accept the same distinction. The SDK and CLI expose both values, while outgoing webhooks include urgency so connected systems can understand how the original event was authored. Retries keep their original identity across the change. Adding the false-by-default field does not change an ordinary Ping's idempotency fingerprint; an urgent send remains distinct from a non-urgent one. The server also derives delivery priority from urgency rather than from an open acknowledgement state. A confirmation-only Ping can therefore keep normal delivery while still carrying the response lifecycle and Live Activity. ## Two Separate Meanings [PingRoom 1.4](/blog/pingroom-v1-4) introduced the combined Urgent-and-acknowledgement behavior. The current source model separates those meanings: Urgent means delivery priority, and confirmation means a human response. Urgent is about arrival. Confirmation is about responsibility.