Answering Questions From Notifications

The Question primitive is only special if the human can answer at the edge.

If every decision requires opening a dashboard, logging into a web app, finding the right task, and clicking through a form, the product has lost the advantage of push. PingRoom's job is to make the decision reachable from the notification layer.

That means answering has to work from both the lock screen and the app.

The Push Payload

A question notification needs enough payload to render actions and resolve a tap.

At minimum, it should carry:

{
  "triggerSource": "question",
  "questionId": "q_123",
  "prompt": "Deploy production now?",
  "context": "Commit abc123 passed CI",
  "options": [
    { "value": "approve", "label": "Approve" },
    { "value": "deny", "label": "Deny" }
  ],
  "responderScope": "direct",
  "correlationId": "deploy-abc123"
}

The exact platform shape can differ, but the tap must include the question id and option value. The server validates both.

iOS Actions

On Apple platforms, dynamic per-question action labels need help from the notification service extension.

The extension can inspect the payload, apply the option labels, mark the notification actionable, and attach the right metadata. A fixed set of pre-registered categories is not enough if every question can have different labels.

Two-option questions are the best lock-screen experience. Approve and Deny can be visible immediately. Three or four options may require expansion, so the product should treat those as the escape hatch.

Android Actions

Android can set per-message action labels when building the notification.

The same principle applies: carry the question id, option values, and labels; make two-option questions fast; validate the tap server-side; and update the notification state after resolution when possible.

In-App Feed

The in-app feed is the second answering surface.

A Question should render as a first-class room history cell. For two options, inline buttons are best. For three or four, a "choose an answer" affordance can open an answer sheet with all options and the time remaining.

The feed cell should also show resolved states:

Approved - by you
Denied - by Mahdi
No answer - expired
Cancelled

The copy should stay spare. PingRoom is not trying to become chat.

Answer Operation

Both surfaces call the same server operation:

POST /api/questions/{questionId}/answer
Authorization: Bearer USER_TOKEN
Content-Type: application/json

{
  "option": "approve"
}

This endpoint is illustrative of the protocol shape. The final route can follow the app's routing conventions, but the operation should stay singular: answer this question with this option as the authenticated user.

Validation

The server must check:

• the question exists
• the question is still pending
• the option value is one of the allowed options
• the authenticated user is allowed to answer under the responder scope
• the expiry deadline has not passed

If the question is already terminal, return the terminal state. Do not create a second answer.

The Human Standard

A person who taps should never feel punished for being second.

If someone else already answered a room-scope question, the UI should say that. If the question expired, the UI should show no answer. If the asker cancelled it, the UI should show cancelled.

That is how the notification layer stays trustworthy. The tap is fast, but the state is precise.