Review queue
Recover, resolve, or discard inbound submissions that could not be processed — nothing sent to SmileLine is ever silently lost.
SmileLine stores every inbound payload — a website form post, a Meta lead, a chat message, a practice-management event — before it tries to process it. When something cannot be processed (a malformed body, an unrecognised event type, an internal failure), the raw payload is kept and appears in the review queue instead of disappearing.
The queue lives at Settings → Review queue, visible to owners and managers. It has two tabs:
- Intake issues — leads that did arrive but reference something that needs fixing. See Intake review.
- Unprocessed payloads — submissions and events that never became a CRM record at all. This page covers that tab.
When anything is waiting, Today shows an amber strip — 3 items need review — and owners and managers get an Incoming data needs review notification — in the bell and, by default, by email, at most one email per item per day however often it is retried. Both open the Unprocessed payloads tab directly, and each tab's label shows how many items are open. See Notifications.
What lands here
| Label | What it means |
|---|---|
| Parked payload | A submission or webhook that failed to process — a form post that wasn't valid JSON, a signed provider event SmileLine couldn't parse, or a message caught by an outage. |
| Stripe event | A signed Stripe event of a type SmileLine doesn't handle, or one for an unmapped account. The event itself stays at Stripe. |
| PMS sync row | A record from your practice-management system that failed to sync. |
| Phone event | A phone-system job that exhausted its retries — including a call or AI-call event SmileLine received but could not deliver to the call after several attempts. Inspect shows the event as SmileLine understood it; Retry gives it one fresh set of attempts; Discard keeps the record but stops further retries. |
| Detected form | The tracking script found a form on your website and somebody has submitted it while it still waits for its field mapping. The row appears only once the first submission arrives — a form nobody has used is not listed — and shows how many submissions are waiting; they are held behind this one row rather than listed separately. Inspect shows the page, selector, fields, when the form was first and last seen, and the count. There is no Retry, Resolve or Discard: click Map fields to open the form in Settings → Website, where confirming the mapping turns every waiting submission into a lead and archiving the form deletes them. See Website forms. |
| Family account proposal | An import or your PMS named a guarantor for a patient, but SmileLine could not open a shared family account on its own: the patient is an adult without a recorded sharing consent, the guarantor already belongs to another family account, or the two guarantee each other. The guarantor relationship itself is recorded; the account waits for your decision. |
Items marked retrying automatically are still being retried in the background; you don't need to act unless they stay stuck. Items marked held arrived while the practice was past its free plan's patient limit: they are stored intact and become leads automatically within a few minutes of the practice subscribing, so there is nothing to retry. The failure line on a row tells you how it got here: one that reads kept for review was never retried, because it needs a person's decision on sight; one that reads moved to manual review used up its automatic retries. Either way the payload is intact and the actions below apply.
Which items offer Retry
Retry appears only where SmileLine can honestly run the payload through processing again. These kinds of parked data gained it recently:
| Source | What it is | What Retry does |
|---|---|---|
capture-file | A website form post whose file uploads could not be stored. The form fields were kept; the files were not. | Recreates the lead without the files. |
outbound-email | An outgoing email retained after delivery could not complete. Provider throttling normally recovers automatically. | Rechecks the delivery and retries it if it is still eligible. Completed deliveries are skipped. |
email-raw | An inbound email that could not be delivered into the inbox — an outage, or a mailbox connection that was paused at the time. | Delivers the email into the inbox. |
referral-suspect | A friend's referral submission that filled the hidden anti-bot field. Browser autofill does this on genuine referrals, so it is parked rather than dropped. | Accepts it as genuine: the referral is submitted. |
pms-webhook-unrecognized | A practice-management webhook carrying an event type SmileLine did not recognise. | Runs it again — useful once support for that event type has arrived. |
lead-ads-unknown-asset | A lead-ad submission for an ad account or Page the practice had not connected yet. | Connect the account under Ads first, then Retry: the lead lands in the practice that owns the account. |
ai-voice-capture | A caller's details the AI receptionist took but could not save during a fault. | Saves the patient and the lead. |
whatsapp-batch | A signed WhatsApp delivery for one of your numbers that SmileLine could not fully place: it carried a message with no sender, or failed mid-processing. Every message in the batch is kept. (A delivery naming a number no connection here owns — disconnected, or belonging to the other region — is held for Smileline support instead, and does not appear in your queue.) | Runs the batch through the inbox again. Messages already delivered are filed as duplicates and announce nothing. |
meta-batch | The same for a Messenger, Instagram or comments delivery on one of your Pages: an unsend that arrived before its message, or a failure mid-processing. A delivery for a Page not connected here is held for Smileline support. | Runs the batch through the inbox again. |
A lead that Retry — or the background replay — creates reaches your team exactly like a live submission: it appears on Today and the bell rings once. A payload that had already landed earlier (a browser retry, a provider redelivery) is filed as a duplicate and announces nothing.
A Detected form row offers none of the three: it stands for the submissions waiting behind it, and they are settled together from Settings → Website.
Some other rows are deliberately not offered Retry — only Inspect, Resolve and Discard — because running them again would fail the same way, or the retry lives elsewhere. The row's note says which: public-form-invalid (the body failed validation; enter the lead by hand), telegram-unsupported (an update kind SmileLine doesn't handle yet), email-loop-suspect (mail from the connection's own address), pms-poll-unmappable (a practice-management record SmileLine could not map), lead-ads-overflow (an evidence copy — its Replay is in the Ads workspace), and an integration lead SmileLine deliberately refused (the sender was told to fix and resend, so a retry here would duplicate their corrected submission).
Phone-system items
Items from the phone system name their source on the row, and what the queue can honestly offer depends on it — some are replayed from here, some recover on their own, and some can only be inspected:
| Source | What it is | What to do |
|---|---|---|
dialer-connections-voicestack | A VoiceStack completed-call webhook whose receipt could not be stored. | Retry replays it. A body SmileLine could not read is not offered a retry — VoiceStack never resends it — so Inspect it, then Resolve or Discard. |
dialer-telnyx-cdr | A desk-phone call record that failed to import. | Nothing — the daily desk-phone usage pull reads these records again. Resolve once it has. The same source also carries a desk-phone move back to SmileLine that used up its attempts (raw_line_teardown_parked): click Move back to SmileLine on the number again to retry it. |
dialer-telnyx-porting | A port-in or port-out event SmileLine could not apply. | Nothing — the porting and port-out pollers re-read the order from the carrier. Resolve once the port shows the right state. |
dialer-telnyx | A signed call or recording event SmileLine could not parse. | Inspect, then Resolve or Discard. There is no retry: the provider never resends it. |
voice-failover-rescue | A call that arrived while SmileLine could not take it — one row per call, written within the hour, titled caller → dialled number → backup so you can ring the caller back. Voice lines forward to their backup number; tracking numbers forward to wherever they normally forward. A Voice line with no backup configured leaves a backup not configured row instead: nobody could be forwarded, but the caller's number is kept. | Ring the caller back if needed, then Resolve. |
dialer-operation (a Phone event) | A verification submission, document upload, number release, port step or desk-phone move that was parked before the provider confirmed it. | Retry re-arms the same operation in place — a fresh set of attempts, the same request, so a provider object that did land is picked up rather than duplicated. Submitting the same thing again from where you started it — Settings → Phone numbers for verification, documents and releases (see If an operation is parked for review), Settings → Call routing for a desk-phone move — does the same. |
recording-unreported (a Phone event) | A voicemail the caller left whose recording the provider never reported back, after an hour of automatic checks. SmileLine keeps asking the provider hourly for up to 30 days; the practice already has a Missed call notification for it. | Retry restarts the fast five-minute checks. Resolve once the voicemail turns up or the caller has been reached another way. |
Clinical storage items
| Source | What it is | What to do |
|---|---|---|
clinical-retention | A clinical document deletion the daily scan proposed and the database refused — the summary carries the reason (a legal hold or a copy that changed under the scan). Nothing was deleted. | Nothing — tomorrow's scan re-evaluates the document on its own. Inspect if the reason is unexpected, then Resolve. |
Act on an item
Click Inspect to see the raw stored payload and why it failed. This is exactly what was received, so you can tell a real enquiry from junk.
Click Retry to run it through processing again — for example after fixing a form's field mapping or reconnecting a provider. Retries are safe to repeat: an already-processed payload is recognised and skipped.
Click Resolve when the item is handled some other way (say, the patient called and was entered manually). The payload is kept; the item leaves the queue with your note.
Click Discard only for junk. Discarding permanently deletes the stored payload and asks why — the decision, who made it, and the note are kept forever.
Inbound data is deleted in exactly two places: Discard here, and Archive on a website form that still holds submissions waiting for its mapping. Nothing in this queue expires on a timer, and no automatic process removes it.
Handled history
Switch to Handled to see previously resolved and discarded items, including who settled each one and the note they left.