Booking WhatsApp tester guide

Version: 3 November 2026. Audience: manual QA testers and the person preparing the staging clinic.

For the customer-facing walkthrough, see Manage WhatsApp booking messages. This document keeps the separate QA procedures and pass/fail checks.

This is a test procedure, not evidence that live messaging has passed. Use it against the deployed build supplied by the test coordinator. Record the build and environment before starting. If the deployed screen differs from this guide, record the difference rather than assuming a button has the same effect.

This guide is part of the public documentation and is accessible without a login. Do not add customer records, real telephone numbers, login links, access tokens, screenshots of private conversations, or test credentials to this page.

#1. What must be proved

The complete journey is:

1. Connect the clinic sender to the correct agent and Booking module.
2. Choose a workflow and starting variation.
3. Define parameters, edit the body, enter synthetic examples, and check the preview.
4. Save a local draft and explicitly submit it to Meta.
5. Refresh the live Meta list and verify the actual approval result.
6. Link the approved name and language to a workflow.
7. Save and reopen parameter-mapping drafts where required.
8. Trigger real booking actions and check the message on the intended test handset.
9. Check delivery evidence, opt-outs, failure handling, duplicates, and retained settings.

Three different things must not be confused:

• A template is wording, language, category, components, and approval status held by Meta.
• A workflow link selects the Meta template name and language for an application event.
• A parameter mapping chooses which workflow value supplies each placeholder. Custom mappings can currently be saved as drafts, but the delivery code still uses its existing ordered contracts. Saving a mapping draft does not activate remapping.

A green preview, successful save, or “queued” result is not proof of delivery.

#2. Test equipment and prepared data

Ask the coordinator to provide all of the following before starting:

1. The staging URL, test account, Booking module, deployed build, and correct local timezone.
2. A connected clinic WhatsApp sender owned by the same account as the Booking module and attached to an agent with that module enabled.
3. Confirmation that the staging sending worker is enabled and inbound messages and delivery callbacks reach staging. A visible server-disabled warning is an environment blocker for live-delivery cases.
4. Two tester-controlled recipient handsets: one patient number and one guardian number. Use a third number for the doctor when possible. The sender and recipients must be different numbers.
5. A test doctor whose Service Provider profile contains the tester-controlled doctor number.
6. A location with future working hours, a bookable service, and no schedule conflicts. Example: MyClinic, Dr. Taylor, Test consultation, 30 minutes, Asia/Kolkata.
7. Synthetic patients: Alex Patient, Sam Guardian, and another unrelated patient for wrong-recipient checks. Use only actual tester-controlled telephone numbers, with country codes, in fields that can send messages.
8. A synthetic treatment worth INR 3,000, with a partial test payment of INR 1,000 and a final payment of INR 2,000. Do not collect a real payment.
9. Existing approved templates for immediate business-flow testing, or time for Meta to review the templates submitted during this exercise. Meta review time is external; do not fail the application merely because approval is still pending.
10. The coordinator’s approved observation period for a send, worker scheduling, and webhook receipts. Record a timeout as pending investigation or blocked until its cause is known; do not keep clicking Send.

Use only synthetic clinical and financial details. Approval of a template does not grant permission to contact unrelated people.

#3. Navigation and save behaviour

Open the Booking manager. Open the Settings gear, then Communications → WhatsApp.

The current WhatsApp area has three sibling tabs:

• Template Library List: live templates from the selected sender’s Meta account. Rows open the preview and linking popup.
• Create from workflows & variations: the local draft editor and explicit submission actions.
• Delivery settings: appointment reminder timing.

The Enable WhatsApp updates switch is in the header. Clinic sender appears beside it only when updates are enabled. The separate clinic-name, visit-instruction, free-text cancellation, and free-text reschedule editors have been removed from this interface.

Save rules to verify:

1. Changes to the enable switch, sender selection, reminder timings, and a newly created local draft use Save Configuration in the Settings header. Reopening a form before saving is not proof of persistence.
2. Submit to Meta is explicit. A compatible submission can automatically save a missing workflow link. An existing explicit link or compatible approved legacy fallback must be preserved. Submission never makes a local draft approved or sends a customer message.
3. Selecting a workflow in the preview popup only chooses the contract to inspect. Link using current sending contract immediately saves the link after server validation. No second Save Configuration action is required for that link.
4. Save mapping draft immediately saves the scoped mapping draft. No second Save Configuration action is required for that mapping draft. It still does not change runtime sending.
5. Removing a workflow override is a separate action. Follow the on-screen persistence instruction and verify after a full reload. A retained older fallback can still be used after an override is removed; “override removed” is not the same as disabling the workflow.

#4. Connection and configuration checks

C01 — Enable and select the sender

1. Open the WhatsApp area with updates disabled. Confirm the Clinic sender dropdown is absent.
2. Enable updates. Confirm the dropdown appears beside the switch.
3. Select the assigned staging clinic sender. Do not substitute another clinic’s number if it is unavailable.
4. Open Delivery settings and select the reminder times required for the test.
5. Click Save Configuration, reload the page, and confirm the switch, sender, and timings remain selected.
6. Disable updates, save, and reload. Confirm the sender dropdown is hidden, then re-enable updates and confirm the previously selected sender and template links remain intact.
7. Restore enabled delivery and save before running positive message tests.

Pass: values persist, disabling does not erase configuration, and opening the page does not automatically change the template name or language.

Blocker: “Choose a clinic-owned sender linked to an enabled agent” or an unavailable sender. Ask the coordinator to repair account/agent/module linkage.

C02 — Inspect the Meta list

1. Open Template Library List and refresh the Meta templates.
2. Confirm the table has Template name, Category, Meta status, and Workflow links.
3. Confirm template names remain on one line. The list has no search bar or status-group filter buttons.
4. Click a row. Check the exact template name, language, category, status, and components in its detail view.
5. Compare at least one approved, pending, and rejected template if these fixtures exist. Do not manufacture a rejection by submitting prohibited content.
6. Verify that a matching local draft does not acquire approval merely because a similarly named template exists.

Pass: displayed approval comes from Meta. Same-name templates in different languages remain distinct.

#5. Create and edit a template

T01 — Start with a sendable registration model

1. Open Create from workflows & variations.
2. Select Patient registration confirmation and Short acknowledgement.
3. Confirm the body and five default parameters appear. Their order is clinic, patient, patient number, mobile, and date of birth.
4. Review the suggested Meta name. For a new submission use a unique lowercase name, such as qa_registration_short_20261103_a, and a supported language such as en. Use the coordinator’s naming convention if one is provided.
5. Change only surrounding wording, keeping all numbered placeholders once each in their existing order.
6. In the parameter form, confirm the workflow-field selectors retain their defaults. Enter fictional example values. Use Alex and MyClinic rather than real patient details.
7. Check that the preview updates immediately with those examples.
8. Hover over or focus the information icon beside Body wording and read its guidance.
9. Click Create local draft. Confirm a draft preview and action buttons appear and it is labelled not submitted.
10. Click Save Configuration. Reload and reopen the draft. Confirm its wording, examples, name, language, and field choices were retained.

Pass: creating/editing a draft never submits it to Meta or sends a WhatsApp message. Examples are preview/submission samples, not actual runtime patient data.

T02 — Add and remove parameters deliberately

1. Start a separate registration draft; keep T01 unchanged for live sending.
2. In the parameter form click Add parameter. Confirm a sixth field appears and the body is unchanged.
3. Choose an available workflow field for it, for example Clinic contact details from additional variation values. Review or edit its synthetic example.
4. Manually type {{6}} into the body where required, with real text after the last placeholder.
5. Verify the draft cannot be saved with an unassigned field or a declared field missing from the body.
6. Remove parameter 2 using its trash icon. Confirm the corresponding placeholder is removed from the body, later placeholders are renumbered, and their selected fields and examples stay aligned.
7. Reopen the saved draft after reload and check all remaining field choices again.

Expected limitation: this is a custom contract. It may be drafted and explicitly submitted with samples, but Meta approval alone does not make it compatible with the existing sender. Do not use this modified draft for a positive delivery test until compatible runtime mapping support is available. The five-value registration sender must not silently start sending six values.

T03 — Body and sample validation

Using a disposable local draft, try each input below separately, restore valid content, and record the result:

1. A missing declared placeholder.
2. An undefined extra placeholder such as {{9}}.
3. A duplicate placeholder or reordered numbers.
4. A named placeholder or malformed braces.
5. A blank example or missing workflow-field choice.
6. A body over 1,024 characters or a blank body.
7. A template name with spaces or uppercase characters, or an invalid language code.
8. A placeholder at the very beginning or end of the message. Add ordinary wording before and after it; punctuation alone is not sufficient for the app’s submission check.

Pass: invalid authoring is explained and cannot be saved/submitted as valid. Validation does not modify existing approved templates or other assignments. If opening/closing text repair is offered, it changes wording only when explicitly clicked.

#6. Submit and verify Meta approval

T04 — Explicit submission and approval

1. Open the valid, saved T01 draft and click Review submission.
2. Confirm nothing has been submitted yet. Cancel once and verify the draft remains local.
3. Review its name, language, body, and synthetic samples. Click Submit to Meta once.
4. Confirm the result is submitted or pending, not locally approved.
5. Refresh Template Library List. Find the exact name and language, open the row, and verify the actual Meta components and status.
6. When Meta approves it, refresh again. Confirm the live status is APPROVED, category UTILITY, and the only component is BODY before attempting a live send.
7. If Meta rejects it, record the rejection, retain the draft details, and correct/recreate it through the supported flow. Do not repeatedly retry an unchanged rejected template.
8. If the request times out or says submission is unconfirmed, refresh the live Meta list first. Do not blindly submit again: Meta may already have created it.

Pass: only an explicit submit action creates a Meta template; approval is always distinguished from draft/submitted status. A duplicate name/language cannot create a second local “approved” result.

T05 — Existing assignments survive new submissions

1. Record the name and language already assigned to two different workflows.
2. Submit a new valid variation for one of those workflows.
3. Reload the library and confirm both existing links remain unchanged. A new variation must not replace an established assignment just because it was submitted.
4. For a workflow with no assignment, submit an eligible unmodified model. If the selected sender and stored settings permit auto-linking, verify the missing link is saved immediately and survives reload without Save Configuration.
5. Confirm the newly submitted template still cannot deliver until it is approved by Meta.

Pass: submission auto-save persists eligible new links and preserves existing links. If an existing compatible legacy fallback prevents auto-linking, keep it and explicitly choose a replacement only after approval.

#7. Link templates and test parameter mapping

T06 — Link an approved compatible template

1. In Template Library List click an APPROVED Utility BODY-only template.
2. In Template preview & workflow linking, select the intended booking workflow.
3. Inspect its suggested parameter sources and ordered contract. Selection alone must not be mistaken for a completed link.
4. Click Link using current sending contract and wait for the server success message.
5. Close the popup and reload the whole page without clicking Save Configuration.
6. Confirm the workflow link remains on the correct template row, with the correct language in its detail view.
7. Trigger one corresponding business event and verify the actual selected template is used.

Pass: the explicit link is saved immediately, not just displayed in local form state. Other workflows are unchanged.

T07 — Save and reopen a mapping draft

1. Open a template row and select a workflow.
2. Inspect the compact parameter rows. The boxed letter identifies the component: B for BODY, H for HEADER, F for FOOTER, or the relevant additional component marker.
3. Check the muted example/helper text. For a submitted template, a Meta-provided example is read-only; changing a source does not edit that submitted example or the Meta body.
4. Change one parameter to another offered workflow field. If fixed text is available, test a synthetic fixed value as a separate mapping choice.
5. Confirm a modified-mapping icon appears where the choice differs from the workflow sending contract. Use suggested mapping and verify the default choices can be restored.
6. Leave one parameter unassigned. Confirm Save mapping draft cannot save an incomplete mapping.
7. Complete the choices, click Save mapping draft, and wait for success.
8. Reload without Save Configuration. Reopen the same sender, template name, language, and workflow. Confirm the draft choices remain.
9. Open a different language or workflow and confirm it does not inherit this mapping accidentally.

Pass: the scoped draft persists immediately. It does not rewrite the Meta body, approval, submitted examples, another mapping, or the active workflow link.

Important: saved custom mapping is not executed by current delivery. A reordered field, fixed value, or extra field must not be presented as active sending support. Use the original compatible contract for positive live-send tests.

T08 — Incompatible and stale template handling

1. Inspect a pending/rejected template, a non-Utility template, a template with HEADER/buttons/footer, and a template with a different parameter count, where such fixtures exist.
2. Verify the application explains why a live link cannot be created. Previewing a header or button is not sending support.
3. Verify a six-placeholder registration contact template shows all six Meta placeholders while explaining that registration currently supplies five runtime values.
4. With coordinator help, change a disposable Meta template’s wording/components after saving a mapping. Refresh and attempt to save the old mapping.
5. Confirm the stale mapping must be reviewed rather than silently applied. Recheck other saved links and drafts.

Pass: approval and contract compatibility are separate checks. An approved incompatible template remains blocked for live linking.

T09 — Persistence and reset regression

1. Record all workflow links, sender selection, a saved local draft, and a saved mapping draft.
2. Reload; log out and log back into the same staging account; recheck all four.
3. Open two browser tabs for the same clinic. In tab A save a link. In the older tab B change an unrelated setting and save configuration. Reload both and verify A’s link remains.
4. If available, edit the same workflow differently in both tabs. A stale change must be reported as a conflict rather than silently erasing the newer saved link.
5. If testing through the admin-created staging workspace, run one non-WhatsApp behavioural test and then one WhatsApp test. Reopen the same module and verify all template links, drafts, mappings, and sender settings remain.

Pass: testing and unrelated settings saves do not reset the staging communication configuration. Record the exact admin test/run ID if a reset occurs. The previous runner reset bug must not reappear.

#8. Evidence required for every delivery test

For each case below:

1. Check that the named workflow has an approved compatible assignment and that the corresponding event is enabled in communication preferences where applicable.
2. Record the booking/patient/campaign reference and exact time, with timezone, before triggering the action.
3. Trigger the action once. Distinguish “saved”, “queued”, and “sent”.
4. Open Settings → Communications → Logs, select the WhatsApp channel if needed, and click Refresh status.
5. Match the event reference/type, recipient role, attempt count, and status. Ask the coordinator for message-ID/webhook evidence if the UI does not expose it.
6. On the intended handset confirm the complete rendered text, sender, all substituted values, and any link destination. Check the other handset received no unintended copy.
7. Capture evidence in the private test report and record the result. No message may contain unresolved {{n}}, another patient’s details, an example such as “Example value 1”, or an incorrect balance/date/time.

Status interpretation:

• pending/queued: waiting for a worker; not a completed send.
• sending: the worker has claimed the message; outcome not yet final.
• accepted: Meta accepted the request; delivery is not yet proved.
• sent/delivered/read: provider status evidence. For end-to-end delivery sign-off require handset evidence and delivered/read evidence where available. Read receipts can be disabled, so read is not mandatory.
• blocked: no send was attempted because a prerequisite failed. Inspect its reason.
• failed: a known failure. Use the supported retry action only after correcting the cause and checking its confirmation.
• unknown: Meta may already have accepted it. Do not resend automatically or repeatedly click Send.
• skipped: intentionally suppressed, for example an obsolete reminder or opt-out.

Use both the business result and handset/log evidence. A successful payment save with a failed notification is not a failed payment, and it must not be entered again merely to resend a receipt.

#9. Booking and patient workflow tests

W01 — Patient registration confirmation

1. Link the five-field patient_registration workflow to the approved registration template.
2. Open Patient Management or the registration flow and register a new synthetic patient with the test mobile and date of birth.
3. Confirm one registration message reaches the intended patient number.
4. Compare clinic, patient name, assigned patient number, mobile, and date of birth against the saved patient.
5. Reopen the patient without creating another registration. Confirm this does not send a second registration acknowledgement.

W02 — Appointment confirmation

1. Link appointment_confirmation and enable appointment-created notifications.
2. Use Book appointment or the patient portal to create a future appointment with explicit WhatsApp consent and the tester’s contact.
3. Confirm the booking is saved and one confirmation reaches that contact.
4. Compare event wording, appointment reference, location, and appointment-local time/timezone.
5. Repeat with a second synthetic patient to detect stale substitutions.

W03 — Walk-in confirmation

1. Link walk_in_confirmation. Open Walk-ins and register/check in a synthetic patient for the test consultation.
2. Confirm the walk-in booking and patient association are correct.
3. Verify one walk-in confirmation with patient name, patient number, service/doctor, date/time, and location.
4. If the patient was newly registered, a registration acknowledgement may also be expected. Count messages per workflow: one registration plus one walk-in message is different from duplicate walk-in confirmations.

W04 — Appointment reminder

1. Link appointment_reminder using its five-value current contract. In Delivery settings enable an appropriate reminder interval and save configuration.
2. Create a confirmed, consenting test appointment far enough ahead that its reminder is not already overdue. Example: select 30 minutes before and book at least 35 minutes ahead, within the configured working hours.
3. Wait for the due time and the coordinator’s worker observation period. Do not change server or handset clocks.
4. Verify one reminder, correct recipient/guardian, doctor, date, time, and instruction value supplied by the existing contract.
5. Refresh repeatedly without modifying the appointment. No second reminder for the same time/interval should be sent.
6. Test suppression separately by cancelling or rescheduling before an unsent reminder. The old reminder must not subsequently deliver. More than 15 minutes late is an expected skipped reminder rather than a late send.

W05 — Reschedule proposal

1. Link reschedule_proposal. Open a consenting confirmed appointment and choose Reschedule.
2. Propose an available new time using Send WhatsApp Proposal.
3. Verify clinic, doctor, old time, new time, and the confirmation link on the patient/guardian handset.
4. Before accepting the proposal, confirm the appointment has not been silently moved.
5. Open the received confirmation link on the test handset and inspect the proposed change. Do not paste private token links into a public issue.

W06 — Patient or guardian reschedule confirmation

1. Link reschedule_confirmation. Accept the proposal from W05, or use the supported patient-requested reschedule path.
2. Confirm the appointment moves once to the new slot and the previous slot is released.
3. Verify the confirmation reaches the designated patient/guardian and contains the same appointment reference, location, and new time.
4. Reuse/refresh an already accepted confirmation link. It must not apply or notify the same change twice.
5. Repeat with a designated guardian contact distinct from the patient. For a guardian-addressed variation requiring extra data, keep the mapping as draft until the sender supports it; guardian recipient routing can be tested with the standard compatible template.

W07 — Doctor reschedule notification

1. Link doctor_reschedule. Ensure the provider’s mobile is the separate doctor test number.
2. Reschedule a confirmed appointment with the patient-and-doctor confirmation option enabled.
3. Verify the doctor gets the doctor template with doctor, patient, service, new time, and location.
4. Verify the patient/guardian gets the patient confirmation, not the doctor’s wording. Expect one message per intended role, not two to each.
5. Repeat without a provider mobile on a disposable provider. Capture the missing-recipient result; it must not route the doctor update to an unrelated number.

W08 — Appointment cancellation

1. Link appointment_cancellation and enable cancellation notifications.
2. Cancel one appointment through the clinic/provider action and its confirmation prompt.
3. Verify Cancelled status, released availability, one cancellation message to the correct contact, and suppressed old reminders.
4. Reopen/refresh the cancelled booking. No duplicate cancellation message should appear.
5. Use another booking to test patient self-cancellation within its policy. Verify the same routing, updated state, and single notification.
6. Test outside the allowed cancellation period. An action rejected by policy must not generate a misleading successful-cancellation message.

W09 — Visit completion

1. Link visit_completion and enable completion notifications.
2. Mark a suitable test appointment Complete through its supported status action.
3. Verify Completed status and one completion acknowledgement for that appointment, with the correct reference, location, and time.
4. Check no reminder remains eligible for the finished appointment.

W10 — Missed appointment / no-show

1. Link missed_appointment to wording clearly different from visit completion.
2. Mark a separate test appointment No-Show.
3. Verify No-show status and one no-show/rebooking message, not a completion thank-you.
4. Confirm no old reminder is sent later. Wrong workflow/template selection is a defect even if the API call itself succeeded.

#10. Estimates, bills and receipts

Open the patient’s treatment/payment view in Patient Management, or the linked treatment billing view supplied by the build. Use a saved test appointment/treatment. Ensure patient/guardian routing is recorded before sending.

W11 — Treatment estimate

1. Link treatment_estimate. Set a synthetic consultation/treatment estimate and choose Send Estimate on WhatsApp.
2. Verify patient, service, doctor, visit date, estimated amount/range, and clinic.
3. Confirm this did not record a payment or silently convert the estimate into a final bill.
4. Test the range/payment-plan variation as an authoring/mapping case if it requires a parameter the current producer does not supply. Do not mark it sendable merely because Meta approves it.

W12 — Treatment bill / balance update

1. Link treatment_bill. Set treatment total INR 3,000, paid INR 0, and the intended payment plan. Keep Send updated treatment bill on WhatsApp selected and save.
2. Verify total 3,000, paid 0, balance 3,000, and plan text on the correct handset.
3. Revise the total or plan on a separate test case and explicitly request the updated bill. Verify revised values, not cached examples or the prior balance.
4. Repeat once with the send option off. The business save succeeds without an unwanted bill message.

W13 — Payment receipt: partial and final

1. Link payment_receipt. Record a synthetic payment of INR 1,000 with the WhatsApp receipt option selected.
2. Verify the payment is recorded once and the receipt has the receipt number, received amount 1,000, total paid 1,000, balance 2,000, method, and correct receipt URL.
3. Open the receipt link and compare it with that payment. It must not expose another patient’s receipt.
4. Record the final INR 2,000. Verify total paid 3,000 and balance 0. Do not use “fully settled” wording on the partial-payment case.
5. Test the send option off on a separate payment. No unsolicited receipt should be queued.
6. If notification fails, confirm the payment still exists. Do not record the same payment again to repair messaging.

#11. Review campaigns and inbound workflow steps

W14 — Follow-up / review invitation

1. Link review_invitation. Open Reviews & Recalls and create a review campaign for a future date, service, and provider.
2. Inspect eligible patients and select only the synthetic patients with tester-controlled contacts.
3. Review the selected template/workflow and create/dispatch the campaign through the displayed action.
4. Verify the intended patients receive one invitation with patient, clinic, treatment/service, and date. Unselected patients must not receive it.
5. Repeat the dispatch action on the same campaign. Already queued/notified recipients must not be duplicated.

W15 — Visiting specialist notification

1. Link specialist_visit and use the specialist-visit campaign flow.
2. Select the doctor and a valid visit date or date range; review the selected synthetic recipients.
3. Dispatch and verify patient, clinic, specialist name, and the correct date/range.
4. Verify it used specialist_visit rather than the review invitation template. Multiple dates should be represented by the supported date/range value; do not invent extra positional values.

W16 — Recall reply: booking link

1. Link recall_booking_link before dispatching a fresh invitation to a test recipient.
2. From that recipient handset reply YES to the current invitation.
3. Verify the campaign records the patient’s confirmation and an approved booking-link template reaches the same recipient.
4. Open the private link, choose an available slot, and confirm one appointment is created and the campaign recipient becomes booked.
5. Reopening the completed booking flow must not create another appointment for the same completed request.

W17 — Recall reply: declined invitation

1. Link recall_declined. Use a different current invitation or a separate test recipient and reply NO.
2. Verify declined state and one appropriate template acknowledgement with the correct review date.
3. Confirm the patient is not marked booked and no appointment is created from the decline.

W18 — Recall reply: preferred time received

1. Link recall_time_received. With a separate current invitation reply with a supported preferred time, such as 10:30 AM.
2. Verify the recorded preference and the approved acknowledgement’s patient, clinic, date, and preferred time.
3. The message must not claim a confirmed booking merely because a preference was received. Verify staff confirmation/booking remains a separate step.

W19 — STOP / START acknowledgement and suppression

1. Link whatsapp_preference to an approved compatible template.
2. Send STOP from the patient test handset. Verify the opt-out is recorded and the approved acknowledgement, if configured, confirms disabled updates.
3. Trigger a new booking notification for the same opted-out recipient. Confirm ordinary delivery is suppressed.
4. Send START. Verify updates are enabled again and the acknowledgement reflects the new preference.
5. Trigger a new consenting booking event and verify ordinary delivery resumes. Previously skipped/unknown sends must not be blindly replayed.
6. With coordinator help, test a missing acknowledgement assignment. The preference itself must still change, with no free-text fallback masquerading as a template send.

#12. Negative tests and the 24-hour window

N01 — No consent or disabled delivery

1. Create a portal appointment without WhatsApp consent. Verify no automatic creation/reminder message is generated for it.
2. Disable updates for a separate consenting appointment before its pending notification is dispatched. Verify the unsent message does not reach the handset.
3. Restore the configuration. Missing consent is specific to automatic creation/reminder behaviour; do not assume a staff-requested financial or reschedule action has identical recipient-selection rules.

N02 — Missing, rejected or incompatible template

1. Use a disposable workflow fixture, not a shared working assignment.
2. Attempt to link a pending/rejected/incompatible template. Expect validation to refuse the active link.
3. With coordinator help, make an assigned fixture unavailable or unapproved after configuration, then trigger its event.
4. Verify an honest failure/blocked outcome with no plain-text fallback and no false “delivered” status. The appointment/payment operation may still succeed independently.

N03 — Duplicate, wrong-recipient and cross-clinic protection

1. Trigger one workflow action and refresh/reopen the page without initiating a new action. Verify no extra send.
2. Use distinct patient, guardian, and doctor numbers in the reschedule tests; verify each role’s message and no unrelated copy.
3. Change a preview example. Trigger a fresh event and verify actual patient/booking values are used, not preview examples.
4. In another assigned staging clinic/account, confirm it cannot select this clinic’s private sender or silently inherit its workflow links. Shared staging sender exceptions must be explicitly prepared by the coordinator; they are not evidence that production isolation is disabled.

N04 — Closed 24-hour customer-service window

1. Reserve a tester recipient who has not sent the clinic a WhatsApp message for more than 24 hours. Sending an inbound test greeting would reopen the window, so do not do that immediately before this case.
2. Record the last inbound-message time in the private test report.
3. Trigger a configured workflow using an approved compatible template.
4. Verify the template reaches the handset and normal delivery evidence appears.
5. If the template is missing or incompatible, expect failure/blocking, not a plain-text substitute.

Meta’s customer-service window resets with a user message; outside it, messages require approved templates. Nexaflow’s booking workflows described here deliberately use templates for these notifications, even when a window is open. See the official WhatsApp Business Messaging Policy, section 2. This guide’s Utility BODY-only and strict positional-order limits are the current application’s sending contract; do not assume they describe every capability available in Meta.

N05 — Failure and retry without duplicate business actions

1. For a definitively blocked/failed notification, record the error and have its cause corrected.
2. Use the supported notification Retry action, including confirmation where requested. Do not recreate the appointment or payment.
3. A retry may retain the event’s captured template and recipient. Changing a workflow link does not necessarily rewrite an already queued event; coordinate a fresh event when testing a new assignment.
4. For accepted, sending, or unknown outcomes, inspect the existing event and callback evidence instead of repeatedly resending. A late callback should update that event rather than creating a new business action.

#13. Admin test runner and stepped execution

This is an additional evidence tool, not a replacement for the real Booking-manager actions above.

1. Open the admin customer/account and WhatsApp & Module Testing area supplied by the coordinator. Confirm the selected account, source module, and staging workspace refer to this same test clinic.
2. Inspect Approved templates and parameter contracts. Confirm templates are fetched live from Meta at test time and the resolved name/language agree with the staging workflow assignments.
3. Run Registration confirmation first in stepped mode if available. Follow the displayed plan: workspace/preflight, template/recipient validation, probe/send or listener start, then delivery and business evidence.
4. At each step record its result. For the send step, inspect the handset. For evidence, wait for the callback; successful dispatch is not the same as delivery.
5. If the run says it is waiting for the runner or delivery evidence, record its diagnostic. Check the runner and webhook with the coordinator. This is not a reason to click Send repeatedly.
6. Pause at the next step and continue through the supported controls. A pause request may take effect only at a step boundary.
7. To abandon a run, use Stop/Cancel and verify terminal state before starting a new run. Cancelling cannot recall a message already sent to WhatsApp.
8. Retry runner connection only through the existing-run control. Record the same run ID and verify it does not create a second send.
9. After a non-WhatsApp test, reopen the staging template library and repeat T09. A runner must not replace this workspace’s communication settings with a source snapshot.

Result labels:

• PASS: all required business, recipient, text, and delivery evidence exists.
• FAIL: reproducible application behaviour contradicts the expected result.
• BLOCKED: sender/worker/webhook, missing approved fixture, permission, external approval, or another prerequisite prevents the test.
• NOT RUN: not executed.
• PENDING EVIDENCE: accepted/unknown/waiting and not yet resolved; this is not a pass.

#14. Test record and defect report

Copy this record into the team’s private test tracker for each case:

Case ID and title:
Tester and test date:
Application build / admin-runner build:
Environment and clinic/module:
Workflow ID:
Template name and language:
Meta category / status / components:
Saved mapping draft or current sending contract:
Patient / guardian / doctor test aliases:
Booking / treatment / payment / campaign reference:
Preconditions and last inbound time for 24-hour-window cases:
Action steps and timestamps with timezone:
Expected business state / recipient / message:
Actual business state / recipient / message:
Notification event / attempt / message ID where available:
Final notification status and handset evidence reference:
Result: PASS / FAIL / BLOCKED / NOT RUN / PENDING EVIDENCE
Defect or blocker reference:
Cleanup completed:
text

For a defect, include minimal reproduction steps, expected versus actual behaviour, the exact non-secret error text, and whether the business operation was saved. Mask telephone numbers and exclude tokens, private booking/receipt URLs, session links, and unrelated patient data from shared screenshots.

#15. Completion and handover

1. Run connection, template management, mapping, persistence, and workflow cases required by the coordinator. Do not mark unexecuted workflows passed because one template delivered successfully.
2. For the main 15 workflows, record W01–W15 separately. W13 includes both partial and final payment. W16–W19 cover the additional recall replies and preference acknowledgements present in the current build.
3. Review guardian routing, duplicate cancellation protection, reminder suppression, the closed-window case, and the non-WhatsApp runner reset regression before sign-off.
4. Record known limits explicitly: custom mapping is saved as draft only; extra-field variations are not automatically sendable; non-Utility or non-BODY templates are not supported by the current sender.
5. Restore the agreed sender, links, reminder timings, opt-in state, and test delivery settings. Stop unfinished runs and remove only coordinator-approved disposable fixtures. Do not delete shared WABA templates or other testers’ links.
6. Hand over pass/fail/block counts, pending Meta approvals, unresolved delivery evidence, defect references, and the exact build tested.

#16. Current ordered workflow contracts

The following reference describes the current named workflow models. Numbers are the actual positional order required for standard live linking. Different labels or a matching number of fields do not make a different order compatible. Existing legacy fallbacks can have older contracts; use explicit named assignments for these tests.

Patient registration confirmation

Workflow ID: patient_registration. 5 parameters.

1. Clinic name (clinic).
2. Patient name (patient).
3. Patient number (patientNumber).
4. Patient mobile (mobile).
5. Date of birth (dob).

Appointment confirmation

Workflow ID: appointment_confirmation. 4 parameters.

1. Booking event (event).
2. Appointment reference (reference).
3. Location (location).
4. Appointment date and time (localTime).

Walk-in confirmation

Workflow ID: walk_in_confirmation. 5 parameters.

1. Patient name (patient).
2. Patient number (patientNumber).
3. Service and doctor (serviceDoctor).
4. Appointment date and time (localTime).
5. Location (location).

Appointment reminder

Workflow ID: appointment_reminder. 5 parameters.

1. Patient or designated guardian name (recipient).
2. Doctor name (doctor).
3. Appointment date (date).
4. Appointment time (time).
5. Visit instructions (instructions).

Reschedule proposal

Workflow ID: reschedule_proposal. 5 parameters.

1. Clinic name (clinic).
2. Doctor name (doctor).
3. Previous date and time (oldTime).
4. Proposed date and time (newTime).
5. Confirm proposed time URL (confirmationUrl).

Patient/guardian reschedule confirmation

Workflow ID: reschedule_confirmation. 4 parameters.

1. Booking event (event).
2. Appointment reference (reference).
3. Location (location).
4. Appointment date and time (localTime).

Doctor reschedule notification

Workflow ID: doctor_reschedule. 5 parameters.

1. Doctor name (doctor).
2. Patient name (patient).
3. Treatment / service (service).
4. Appointment date and time (localTime).
5. Location (location).

Appointment cancellation

Workflow ID: appointment_cancellation. 4 parameters.

1. Booking event (event).
2. Appointment reference (reference).
3. Location (location).
4. Appointment date and time (localTime).

Visit completion

Workflow ID: visit_completion. 4 parameters.

1. Booking event (event).
2. Appointment reference (reference).
3. Location (location).
4. Appointment date and time (localTime).

Missed appointment / no-show

Workflow ID: missed_appointment. 4 parameters.

1. Booking event (event).
2. Appointment reference (reference).
3. Location (location).
4. Appointment date and time (localTime).

Treatment estimate

Workflow ID: treatment_estimate. 6 parameters.

1. Patient name (patient).
2. Treatment / service (service).
3. Doctor name (doctor).
4. Appointment date (date).
5. Estimated amount or range (estimate).
6. Clinic name (clinic).

Treatment bill / balance update

Workflow ID: treatment_bill. 6 parameters.

1. Patient name (patient).
2. Treatment / service (service).
3. Total bill (total).
4. Total paid (paid).
5. Balance remaining (balance).
6. Payment plan (plan).

Payment receipt

Workflow ID: payment_receipt. 8 parameters.

1. Patient name (patient).
2. Treatment / service (service).
3. Receipt number (receipt).
4. Payment received (amount).
5. Total paid (paid).
6. Balance remaining (balance).
7. Payment method (method).
8. Receipt URL (receiptUrl).

WhatsApp updates: STOP / START acknowledgement

Workflow ID: whatsapp_preference. 4 parameters.

1. Clinic name (clinic).
2. Patient mobile (mobile).
3. WhatsApp update preference (preference).
4. Appointment date and time (localTime).

Recall reply: booking link

Workflow ID: recall_booking_link. 4 parameters.

1. Patient name (patient).
2. Clinic name (clinic).
3. Treatment / service (service).
4. Choose an available appointment URL (choiceUrl).

Recall reply: declined invitation

Workflow ID: recall_declined. 4 parameters.

1. Patient name (patient).
2. Clinic name (clinic).
3. Treatment / service (service).
4. Appointment date (date).

Recall reply: preferred time received

Workflow ID: recall_time_received. 4 parameters.

1. Patient name (patient).
2. Clinic name (clinic).
3. Appointment date (date).
4. Appointment time (time).

Follow-up / review invitation

Workflow ID: review_invitation. 4 parameters.

1. Patient name (patient).
2. Clinic name (clinic).
3. Treatment / service (service).
4. Appointment date (date).

Visiting specialist notification

Workflow ID: specialist_visit. 4 parameters.

1. Patient name (patient).
2. Clinic name (clinic).
3. Doctor name (doctor).
4. Specialist visit dates (dates).