Skip to main content

Alert resolution UI development

Build the SCO screens that react to the AI Box's MQTT alerts. After a transaction is scanned, the AI Box may publish an alert flagging items that need attention (e.g. an item left unscanned). The SCO shows a resolution flow, lets the customer or staff resolve it, and reports the outcome back.

This can be built against mock alerts, so it runs in parallel with model fine-tuning.

note

The screens below are a generic reference, not a prescribed design — your real UI is your own. What matters is the flow and the API calls at each step, which are the same across vendors.

Each MQTT alert carries an alert_id and a list of issue_items (see Subscribe to alerts for the full payload). When receiving an alert, the SCO should report the resolution outcome, e.g. rescan, or scan_not_required.

Try it — clickable prototype​

Completing a scan makes the SCO wait for the AI Box's MQTT verdict: no alert → payment, alert → the resolution popup. From the popup, Rescan Items and Get Help branch to the customer or staff flow. Click through it — the panel logs the calls each action makes.

Customer view
Total$0.00
Prototype only — simulate the customer scanning an item

Scanning page

The customer scans (or rescans) items — each scan adds an item and sends item-added. Tapping Pay sends scan-completed, which tells the AI Box to verify.

API call log

Click a button on the screen. Rescan Items and Get Help branch to different flows.

API summary — customer vs staff​

An "item left" alert can be resolved by the customer or by staff. Both screens report the outcome with the same call, Update Alert (PATCH /v1/events/alerts/{alert_id}). Only the payload differs:

  • managed_by says who resolved the alert: customer or staff.
  • issue_items gives each flagged item its own managed_result: rescan, scan_not_required, or already_scanned (the item was in fact already scanned — treated the same as scan_not_required). Echo back the exact item_id values from the MQTT alert's issue_items — this is an AI-tracking ID, not the same item_id you sent via item-added, so don't try to match it against your own records.

After the alert is resolved, if any item needs a rescan, the SCO returns to the scanning page and calls POST /v1/events/{sco_id}/scan-started. If no item needs a rescan, it moves on without that call.

Item 1$2.20
Item 2$1.80
Item 3$3.10
Total$7.10
Heads up! 2 items may need a rescan
Please review each one before continuing
Item 1
Item 2
Rescan ItemsGet Help
Customer view

Customer view — Rescan Items

The customer rescans the flagged items themselves.

Call APIs
  • PATCH /v1/events/alerts/{alert_id}
    {
  "managed_by": "customer",
  "issue_items": [
    {
      "item_id": "item_1",
      "managed_result": "rescan"
    },
    {
      "item_id": "item_2",
      "managed_result": "rescan"
    }
  ]
}
  • Then, if items need a rescan:POST /v1/events/{sco_id}/scan-started — back to the scanning page
Item 1$2.20
Item 2$1.80
Item 3$3.10
Total$7.10
2 items may need rescan
Please confirm each item before continuing
Item 1rescan
Item 2scan not required
Confirm
Staff view

Staff view — Confirm

Staff review each item and confirm the resolution per item.

Call APIs
  • PATCH /v1/events/alerts/{alert_id}
    {
  "managed_by": "staff",
  "issue_items": [
    {
      "item_id": "item_1",
      "managed_result": "rescan"
    },
    {
      "item_id": "item_2",
      "managed_result": "scan_not_required"
    }
  ]
}
  • Then, if items need a rescan:POST /v1/events/{sco_id}/scan-started — back to the scanning page