Review queue
Try again, mark as handled, or delete inbound items 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), what arrived 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:
- Leads to check — leads that did arrive but reference something that needs fixing. See Intake review.
- Couldn't be processed — 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 Couldn't be processed tab directly, and each tab's label shows how many items are open. See Notifications.
Read an item
Each item tells you what to do:
- The title says what arrived, in plain words — for example Website form submission, Inbox message or Phone system update.
- The status says who needs to act:
- Needs action — it waits for you.
- Retrying automatically — Smileline is still retrying it in the background. You don't need to do anything unless it stays stuck.
- Waiting for subscription — it arrived while the practice was past its free plan's patient limit. It is stored intact and becomes a lead automatically within a few minutes of the practice subscribing, so there is nothing to retry.
- What to do is the next step for this item.
- Reason is the technical reason it could not be processed, for Smileline support. A reason 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 what arrived is intact.
The main button beside an item is the recommended action. View details and Delete sit in the item's More menu (⋯).
Act on an item
Click View details to see what arrived, why it failed, and its source. What arrived is exactly what was received, so you can tell a real enquiry from junk.
Click Try again to run it through processing again — for example after fixing a form's field mapping or reconnecting a provider. Trying again is safe to repeat: something already processed is recognised and skipped. If Smileline is retrying that item at the same moment, you see Couldn't try again — nothing was changed: press it again in a few minutes.
Click Mark as handled when the item is dealt with some other way (say, the patient called and was entered manually). What arrived is kept; the item moves to Handled with your note.
Choose Delete from the More menu only for junk. Deleting permanently removes what arrived and asks why — the decision, who made it, and the note are kept forever.
Inbound data is deleted in exactly two places: Delete 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.
What lands here
Data kept from a provider or your website is titled by where it came from: Website form submission, Chat widget message, Online booking, Friend referral, Ad lead, Lead from a connected app, Inbox message, Email, AI calls, Call that couldn't be answered, Phone system, Practice-management sync, Insurance or accounting reply, Clinical storage or Google review notification. It covers a form post that wasn't valid JSON, a signed provider event Smileline couldn't parse, or a message caught by an outage. Anything else is titled Incoming data.
| Title | What it means |
|---|---|
| Billing event from Stripe | A signed event from your connected Stripe account (online deposits and card readers), kept exactly as Stripe sent it because Smileline couldn't use it: one it couldn't read, a kind it doesn't act on yet, or one that still failed after every attempt. View details shows the event; Try again runs it through the same processing as Stripe's own delivery, so a payment or refund is never recorded twice (one Smileline couldn't read has no Try again). An event for a Stripe account no practice is connected to is held for Smileline support instead. The same title marks a booking deposit paid online that couldn't go on the patient's account, with the reason: usually that the practice had no location (add one in Settings → Locations), or that the account refused it, for example because the Online payment method is archived. Once the reason is fixed, the payment (and any refund since) is added within a few minutes and the item clears itself. It has no Try again, and the payment should not be recorded again by hand. A refund Stripe reports before the payment it refunds shows here as Retrying automatically until the payment arrives, then goes on the patient's account with it. It needs you only if Stripe can't be read (for example its access was removed — fix that, then Try again), lists more refunds than one read returns, or the payment never became the deposit's: then check them in Stripe and record what the account is missing. |
| Practice-management record | A record from your practice-management system that failed to sync, or one held for your decision: a change that contradicts the record Smileline already has at the same revision (or carries no revision to order it by), or a financial record whose amounts, dates, currency or references don't add up, or that names no patient at all. Try again sends it back through syncing right away, rather than leaving it for the next hourly sync; if the cause is still there, it comes back here. A brief database hiccup (a lock wait, a deadlock, a timeout) is retried automatically instead of landing here — unless the same record hits one ten syncs in a row, when it lands here with that reason so it can't stall out of sight. A change for a patient who was erased in Smileline is held here too, with the reason patient_erased, and never brings them back: they are erased in Smileline, so erase them in your practice software too, then Mark as handled. |
| Phone system update | 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. View details shows the event as Smileline understood it; Try again gives it one fresh set of attempts; Delete keeps the record but stops further retries. |
| New form found on your website | The tracking script found a form on your website and somebody has submitted it while it still waits for its field mapping. The item 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 item rather than listed separately. View details shows the page, selector, fields, when the form was first and last seen, and the count; while the form stays the same, the page and the last-seen time update at most once an hour. There is no Try again, Mark as handled or Delete: 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 suggestion | Your practice management system named who pays for a patient (their guarantor), but Smileline did not link them. The reason leads the item: linking from the practice system wasn't switched on yet when it arrived; the payer is paid for by someone else, or the two pay for each other; the patient has a payment plan on their own account; a card reader payment for the patient is still going through; their link to that payer was ended before; or someone at the practice linked a different payer. Nothing is linked or moved. While the reason can clear — linking switched on, the plan cancelled or completed, the card payment finished, who pays corrected in the practice system — Try again links them; if the reason still applies, nothing changes and the item stays. A link that was ended, or that the practice made, is never changed by a sync, so those offer no Try again. See Family accounts. |
| Automation step | A follow-up step or booking message that still failed after several attempts, so Smileline paused it instead of stopping it — or one whose automatic retries ran out while it was still being worked on. Nothing retries it on its own. Try again runs it now, or at its usual time if that is later, and a message is never sent twice; the patient's timeline shows who pressed it. If the step is still being worked on, Try again says so: press it again in a few minutes. A booking message that is switched off needs switching back on first. If the patient has since replied or opted out, or the appointment no longer qualifies, nothing is sent and Try again says it can't be tried again: mark it as handled. Mark as handled leaves paused follow-ups paused; stop them from the lead's enrollment chip if they should not continue. |
Which items offer Try again
Try again appears only where Smileline can honestly run what arrived through processing again. The tables below are keyed by the source shown in View details. These sources gained it recently:
| Source | What it is | What Try again 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 Try again: 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. |
ai-voice-stop-contact | A caller asked the AI receptionist not to be contacted again (or said it was the wrong number), and Smileline could not save the request at that moment. It shows as Retrying automatically while it is retried every 5 minutes, and needs action only once those retries run out — or straight away when the call had no lead to attach it to. Until it is saved, the number can still be rung. | Saves the request, dated when the caller asked: the phone opt-out, an urgent task and a timeline entry, once per call. A call with no lead has nothing to attach it to: set the phone opt-out on their record (or add the number to the do-not-call list), then mark it as handled. |
zapier-lead | A lead a connected integration (Zapier, your own app or an API key) sent while the practice could not take leads — no current subscription, closing, still being set up, or in the middle of a Core Practice Transfer. The integration was refused as usual, but the lead was kept. | Creates the lead once the practice can take leads again, as long as the key or app that sent it can still create patients and enquiries; until then the item stays here. A lead from a sender that was never allowed to create leads has no Try again: view the details, then mark it as handled or delete it. A resend from the integration resolves to the same enquiry. |
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. |
stripe-connect | A signed event from your connected Stripe account, kept as it arrived: a kind Smileline doesn't act on yet, or one that still failed after every attempt. | Runs it through the same processing as Stripe's own delivery. A payment or refund already recorded is never recorded twice. |
meta-batch | The same for a Messenger, Instagram or comments delivery on one of your Pages: an unsend that arrived before its message, a message or button tap with no sender (or, when your Page sent it, no recipient), a reply your Page posted that Smileline can't attribute to anyone, 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 Try again — or the background replay — creates reaches your team exactly like a live submission: it appears on Today and the bell rings once. Something that had already landed earlier (a browser retry, a provider redelivery) is filed as a duplicate and announces nothing.
A New form found on your website item offers none of the three: it stands for the submissions waiting behind it, and they are settled together from Settings → Website.
Some other items are deliberately not offered Try again — only View details, Mark as handled and Delete — because running them again would fail the same way, or the retry lives elsewhere. The item's What to do line 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 Try again is in Ads → Lead capture), and an integration lead Smileline deliberately refused (the sender was told to fix and resend, so trying again here would duplicate their corrected submission).
A lead-ads-overflow evidence copy distinguishes a provider refused the lead lookup failure from a lead that was received but could not be normalised. A lookup refusal includes the provider's HTTP status and error codes when available. Check access to the lead in the provider, then use Retry in Ads → Lead capture. Marking the evidence copy as handled does not import the lead.
If a meta-batch item contains a Page reply to a comment that is not yet in your inbox, Try again looks up the original comment and places both messages in the same conversation. After a connection or processing problem is fixed, try the waiting item again: deploying a fix does not itself clear items already held for manual review. If Meta still cannot provide the comment or its author, the item stays available for review.
Phone-system items
What the queue can honestly offer for a phone-system item depends on its source — some are tried again from here, some recover on their own, and some can only be viewed. Each item's What to do line says which:
| Source | What it is | What to do |
|---|---|---|
dialer-connections-voicestack | A VoiceStack completed-call webhook whose receipt could not be stored. | Try again replays it. A body Smileline could not read is not offered Try again — VoiceStack never resends it — so view the details, then mark it as handled or delete it. |
dialer-connections-justcall, dialer-connections-aircall | A JustCall or Aircall delivery Smileline kept but could not process: its signature no longer verified (the API key was reset in the provider — reconnect first), it arrived before Aircall's verification token was stored, its timestamp was outside the replay window, the call was re-notified more times than Smileline re-reads on its own, its import ran out of time, or its receipt could not be stored. | Try again replays it through the same path a live delivery takes (after reconnecting, for a signature failure). A body Smileline could not read, or an event it does not handle, is not offered Try again — JustCall stops after five attempts and Aircall disables the webhook after repeated failures — so view the details, then mark it as handled or delete it. |
dialer-telnyx-cdr | A desk-phone call record that failed to import. | Nothing — the daily desk-phone usage check reads these records again. Mark as handled 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 carrier's port order is checked again on its own. Mark as handled once the port shows the right state. |
dialer-telnyx | A signed call or recording event Smileline could not parse. | View the details, then mark it as handled or delete it. There is no Try again: the provider never resends it. |
voice-failover-rescue | A call that arrived while Smileline could not take it, titled Call that couldn't be answered — one item per call, written within the hour, with a reason that reads caller → dialled number → backup so you can ring the caller back. Voice lines forward to their backup number; tracking numbers forward to their location's phone. A Voice line with no backup configured, or a tracking number whose location has no phone, leaves a backup not configured item instead: nobody could be forwarded, but the caller's number is kept. | Ring the caller back if needed, then Mark as handled. |
voice-call-cleanup (a Phone system update) | A call that ended, but Smileline couldn't confirm every line on it was hung up. One item per call. | Try again hangs up any line still connected and closes the call. Mark as handled once it succeeds. |
dialer-operation (a Phone system update) | A verification submission, document upload, number release, emergency registration, port step or desk-phone move that was parked before the provider confirmed it. | Emergency registrations that exhausted processing or delivery attempts offer Try again here; see below. For other operations, submit 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. |
voice-capacity-sync (a Phone system update) | A change to the practice's billed add-ons (extra lines, numbers, SMS numbers, extra locations) that could not be applied to its Smileline subscription. The reason shows the quantities and why. | Try again once the reason is cleared: it applies the same quantities again. Contact Smileline support if the reason names a missing price. |
dialer-dlq (a Phone system update for a recording) | A call recording that could not be saved after its automatic retries. | Try again starts one more save attempt. Other dialer-dlq items can only be viewed, then marked as handled or deleted. |
voice-recording (a Phone system update) | The phone provider's copy of a call or voicemail recording that Smileline could not confirm deleted after five attempts. The reason ends with why the last attempt failed: the provider refused the deletion, the phone system was not set up, a legal hold covers the call, or the attempt never reported back. Smileline counts the copy as deleted only when the provider confirms it or reports it already gone. | Clear the reason first (set up the phone system, or wait for the hold to be released), then Try again starts five more attempts. |
recording-unreported (a Phone system update) | 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. | Try again restarts the fast five-minute checks. Mark as handled once the voicemail turns up or the caller has been reached another way. |
call-activity (a Call timeline entry) | A call whose entry on the patient's timeline could not be saved. Smileline retries it automatically four times within about an hour of the call before it lands here; the call itself stays in the call log throughout. | Try again saves the entry again. If it still fails, contact Smileline support with the reason shown. |
For an emergency registration that stopped after repeated processing or
delivery failures, Try again on the newest dialer-operation item resumes
the saved registration. Smileline checks whether the carrier has already
activated that address. The item remains in Handled as recovery history;
the number's registration state shows when emergency calling is ready.
Older registrations cannot replace newer ones. A carrier rejection requires
correcting its stated cause before registering again. See
Emergency calling.
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 reason says why (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. View the details if the reason is unexpected, then Mark as handled. |
Erased patients' kept records
When an erased patient's claims and invoices are kept, providers can still send work about them: an insurer's remittance, a claim's delivery to the clearinghouse, a line of an NHS pay schedule, or a Sistema TS report. Whatever would be a task for anyone else's claim — a remittance line Smileline couldn't post, a claim that couldn't reach the clearinghouse or needs reconciling, a schedule line it couldn't match, an invoice it can't report — lands here instead, titled Erased patient's kept record. The item names no one: no patient, claim reference, code or amount. A payment that does match is still recorded on the kept claim, as for any patient.
There is one item per thing the provider sent: per remittance line, per delivery attempt, per schedule line, and per invoice. When the same work comes round again — Sistema TS is checked every day, for example — it adds nothing: an open item stays the one item, and one you've marked as handled stays handled. Another invoice or line always gets an item of its own. Work about an earlier record that was merged into the erased patient is handled the same way, and leads to the same kept record.
Only the practice owner can settle it, whatever a manager's permissions:
Click Kept record to open the erased patient's kept record — the same view as Download kept record, recorded the same way.
Click View details to see what the provider sent — the remittance line, the delivery attempt or the schedule line, with its references and amounts — or the invoice Sistema TS can't take. Anyone else sees only what the list shows.
Deal with it outside Smileline if it needs it — with the insurer, the clearinghouse, the NHS Business Services Authority or Sistema TS — then click Mark as handled. Who settled it, and when, is recorded.
It has no Try again, because nothing in it can run again, and no Delete: what the provider sent stays with the kept record. Managers see the item, and the Incoming data needs review notification, but can't settle it.
Patient forms
Answers a patient sent from a form link that couldn't be filed on their own are titled Patient form. They hold a patient's health answers and signature, so only the practice's own team signed in to Smileline with the clinical workspace can open them: a practice API key or a connected app can't, and Smileline support sees only that the item exists. Try again needs a role that can fill in forms for patients.
| The reason says | What to do |
|---|---|
| Sent after the link was cancelled, expired or locked | Try again files the answers on the patient's record, waiting for a clinician's review. |
| The link was already used, with other answers | Try again files these answers as a correction of the latest answers filed through that link. |
| Sent from a device that was behind (newer answers had been saved on another device) | Compare them with the patient's latest answers. Try again files these, waiting for a clinician's review; the other device can still send its own. |
| The person who signed may not sign for the patient now, or isn't the signer the link names | Check Details › Family, then Try again — or enter the answers with Fill in and mark this as handled. Try again can't file answers signed by someone other than the link's signer: enter them with Fill in, or send the right signer a new link. |
| The answers couldn't be read, or don't fit the form | View them, enter them with Fill in at the desk or send the patient a new link, then mark this as handled. |
| The patient's record was merged into another | Open that record and use Fill in with these answers, or send a new link, then mark this as handled. |
Delete is refused while the item names a signature that hasn't been stored on the record yet: Try again stores it first. If one person deletes an item while another presses Try again on it, whichever lands first decides: a deleted item is never filed. When the patient is erased, their items go with them.
Answers not sent by the patient
The page saves a patient's answers while they type (see Saving and carrying on). Those saved answers stay private while the link works, except in three cases, each titled Patient form draft and marked not sent by the patient:
| The reason says | What to do |
|---|---|
| Typed after the link was used, cancelled, expired or locked | View them, and enter anything that matters with Fill in or send the patient a new link, then mark this as handled. They can't be filed: a draft is never signed. |
| The page could not read them | Where Try again is offered, it reads them again and, if they can be read now, puts them back in the patient's draft so they can carry on. Otherwise view them, enter what matters with Fill in, then mark this as handled. |
| Answers they were typing couldn't be saved as their draft | Try again saves them so the patient can carry on. If the link has closed since, there is nothing left to save them to and the item clears. |
Answers still waiting to be saved show here while Smileline retries them, but you can't view them until they have failed for good, and you can't mark them as handled meanwhile: that would drop the patient's answers unseen. Wait for them to be saved or to come back for review, or Delete them to discard them on purpose.
Each device keeps at most one such item open: newer typing from the same device replaces it, and the older item is marked as handled with that reason. Delete removes the saved answers too.
Handled history
Switch to Handled to see items your team has already marked as handled or deleted, including who settled each one and the note they left.