Setup & status
What is built, what needs a separate connection, and what is awaiting approval. Live messaging stays paused until you approve a controlled test.
1 · Database & authentication
In-browser store with normalized phone, stable member + assignment IDs, audit trail. Enforced role rules mirrored for the server.
Enable the managed backend (More → Cloud) to move storage + per-role permissions server-side. Without it, accounts are demo and permissions are UI-only.
Random 6-digit codes, 10-min expiry, 5 attempts, 3 resends. No fixed demo code in production.
2 · CRM contact syncing
Connected: trackingId tk_c56d97104a3… · location iZ2CDyJYICjrOeB68ZmT. Registrations sync member records (member ID + CRM contact ID) without overwriting donor info, tags, or comms preferences.
Same number reuses the existing contact; no overwrites; conflicting identities require admin review.
3 · Messaging senders
Connect a WhatsApp Business sender in the messaging platform. Templates below must pass Meta review (UTILITY, en_US).
Configure an SMS sender/number. SMS consent is tracked separately from the empty WhatsApp footer.
Paused (pilot pending your approval). Admins can resume from the Admin dashboard.
4 · WhatsApp templates (awaiting Meta review)
UTILITY · en_US · header none · footer empty · button "View my shifts" → MEMBER_PORTAL_URL. Approved ID: —. On rejection, real status + reason shown (never relabeled approved).
UTILITY · en_US · header none · footer empty · button "View my shifts" → MEMBER_PORTAL_URL. Approved ID: —. On rejection, real status + reason shown (never relabeled approved).
UTILITY · en_US · header none · footer empty · button "Check in" → MEMBER_PORTAL_URL. Approved ID: —. On rejection, real status + reason shown (never relabeled approved).
UTILITY · en_US · header none · footer empty · button "View my shifts" → MEMBER_PORTAL_URL. Approved ID: —. On rejection, real status + reason shown (never relabeled approved).
UTILITY · en_US · header none · footer empty · button "View my shifts" → MEMBER_PORTAL_URL. Approved ID: —. On rejection, real status + reason shown (never relabeled approved).
{{1}}=first name · {{2}}=khane · {{3}}=registration/update id · {{4}}/{{5}}=start/end (12h). Realistic samples supplied; no literal placeholders sent to volunteers.
Configured centrally → https://akfusa.org/volunteer. No placeholder or test URLs sent.
5 · Workflows & delivery
Build in the messaging platform using unique event keys (submissionId+type, assignmentId+type, messageId+sms_fallback) to dedupe retries. Recheck consent + assignment status before each send.
WhatsApp delivered/read → stop; failed/undelivered + SMS consent → one fallback; pending/unknown → wait/flag. 'Not read' is not a failure.
Purpose, channel, template name + approved ID, provider message ID, attempt time, delivery status, failure reason, SMS fallback flag.
6 · NDA & captain assignments
Required for every member before first shift: https://www.akfusa.org/akfusa-nda/. Opening the link / 'I signed' does not count as verified.
If a signing-completion integration is available, connect it; otherwise an authorized captain/admin inspects the signed record and verifies manually. Verifier + timestamp recorded.
Current: 1 assignment(s). Admins assign/revoke from Admin dashboard or Access page.
7 · Controlled test
Executes many-date registration, duplicate no-op, cross-khane block, standby, check-in idempotency, fallback rules.
Remaining manual steps: (1) enable the managed backend for real auth + storage; (2) connect a WhatsApp sender and submit the five templates for Meta review; (3) configure an SMS sender; (4) connect an NDA signing-completion integration if available, else verify manually; (5) build the six messaging workflows with the documented event keys; (6) approve a controlled pilot, then unpause messaging from the Admin dashboard.
