> ## Documentation Index > Fetch the complete documentation index at: https://docs.myfundingmachine.com/llms.txt > Use this file to discover all available pages before exploring further. # Onboarding engine rollout > Review the customer audience, process bounded batches, and enable new-customer enrollment safely. Account linking and Labs enrollment do not authorize customer messages. The engine uses a separately reviewed customer audience and an explicit communication allowance. The original rollout contains 13 customers and one internal pilot; review customer membership separately from test records. ## Audience and batches Technical staff configure the original reviewed list through `onboardingEngineLiveStore:configure` while the engine is paused and its current lease has finished. A configuration accepts up to 100 manually reviewed members and 100,000 characters of JSON. Each member needs current progress, history, consent and workflow-ownership evidence, exact action kinds and communication IDs. Use `mode: "compute"` to inspect proposed actions without claiming or dispatching. Configuration stores each member separately. Every ten-minute engine pass reads at most ten active members, continuing from a persisted cursor. A 13-customer list therefore takes two passes to visit. The cursor advances before provider calls so an unavailable account cannot prevent the next page from being checked. Existing one-write-per-contact limits, uncertain-send holds, receipts, mapping checks and pause controls still apply. A claim cannot target a customer outside that run's selected batch. Previously configured engines keep their saved pilot behavior until staff run configuration again. The change does not migrate or enable a production audience on deployment. Replacing the manually reviewed list deactivates removed manual members; automatically enrolled customers and communication history remain intact. Reconfiguration preserves each existing member's pause and enrollment source. Resume an individually paused member explicitly through `manage`. ## New customer policy `onboardingEngineAudience:configureEnrollment` accepts a reviewed policy while the engine is paused. It requires `enabled`, `mode`, an immutable `startsAt` message-cutover timestamp, review evidence, permitted action kinds and exact communication IDs. It defaults to absent/off. Configuration does not enable the engine. Payment welcomes retain their separate verified-payment policy. For a **new paid customers only** rollout, set `requireVerifiedPayment: true`. A linked subscription, trial, saved card or **New — Paid** CRM stage does not prove that payment was collected. This option requires an unpaused verified payment welcome for the same Operations contact and opportunity, paid on or after both policies' cutoffs, with the payment policy in send mode. A payment arriving after account linking is picked up by the recovery pass. An expired intake link does not invalidate the payment or stop the later sequence. The requirement is stored with each admitted member and checked again before every action. Editing the enrollment template does not remove it from existing members. Staff member edits that omit the field preserve its saved value; changing it requires an explicit boolean and the existing staff review reason. Pausing the payment record blocks their later actions; resuming it restores eligibility without clearing receipts. Existing reviewed cohorts remain unchanged when the option is absent. Automatic admission requires all of the following: * The original CRM creation timestamp was verified by new-customer enrollment on or after October 5, 2026 at 06:00 UTC. Reinstall timestamps do not qualify. * The installed customer still belongs to the Operations agency and is not an internal, agency or transferred Location. * **Onboarding & Setup** remains enabled and the confirmed account link agrees with the Operations contact binding. * An explicit agency-wide setup disable blocks admission and claims, even if the customer Location still has an enabled override. * The customer has no existing audience identity or conflicting contact/product membership. Existing pauses and reviewed allowances are never overwritten. A new customer created before the policy's message cutover is admitted in **compute mode**, even when the policy allows sending for later customers. Staff must review earlier messages and workflow ownership before promoting that member. This catches the rollout gap without replaying a backlog of messages. Link completion requests admission immediately. Every ten minutes a recovery pass checks one page of up to 100 agency installations, saving its cursor for the next pass. It catches already-linked customers after policy activation without scanning the full agency in one transaction. Per-customer conflicts fail separately and are logged for staff review; one conflict does not block the rest of the page. For a Location enrolled automatically before creation evidence was persisted, technical staff rerun `onboardingEnrollment:afterProvisioning`; it verifies the CRM creation date again without changing an explicit manual Labs choice. ## Review, pause and resume Use `onboardingEngineAudience:list` to inspect active or inactive members in pages of at most 100. The old configuration JSON represents the manually configured list; it is not the complete audience after automatic enrollment. With the engine paused and its lease finished, technical staff use `onboardingEngineAudience:manage` with the full reviewed member, `active`, an admin actor and a reason. This supports allowance edits, promotion from compute mode, individual pause (`active: false`) and resume (`active: true`). It does not erase communication receipts or resolve uncertain sends. Disabling the enrollment policy stops new admissions; it leaves existing members unchanged. Pause the engine to stop dispatch for everyone. For automatically admitted customers, Labs opt-outs, transfers and changed account links are checked again immediately before a claim. Re-enable the policy to resume admissions. ## Before enabling sends Review the exact proposed messages and state changes, actual conversation history, current appointments, opt-outs and native workflow ownership. CRM activity entries are not customer replies. A scheduled or confirmed appointment is not proof of attendance. Missing message history is not proof that nothing was sent elsewhere. Keep pre-cutover reminders and MIA changes in compute mode until reviewed. Use `recordHistoricalReceipt` only for explicitly verified equivalents with provider receipts; do not invent receipts or treat a similar message as the same engine communication automatically. Verify the designated internal test contact, sender, permitted delivery channels, form prefill and calendar handoff before requesting the exact production cutover. An SMS STOP opt-out must remain respected during testing. The payment-welcome cutover and removal of the old workflow's email/SMS actions are separate steps; see [Onboarding notifications](/staff/onboarding-notifications). ## Post-form Slack invitation cutover Deploying the templates alone preserves the Slack invitation in the paid welcome. For a separately approved production activation: 1. Pause the engine and let its current pass finish. Review new paid customers only, exact account mappings, history, channel permissions, and native workflow ownership. 2. Review compute output. Configure new-customer enrollment in send mode with `send_email` / `E1b` and `create_task` / `W3-slack-recovery`. Check existing new-paid audience members separately: changing enrollment never overwrites saved members. 3. Set the welcome policy's `slackInviteInE1b` to `true` only after those allowances are ready. The configuration guard rejects a missing, compute-only, or incomplete enrollment policy, or a cutoff that would leave welcome recipients in compute mode. Preserve the existing cutoff and receipts. 4. Verify inbound reply routing with the designated internal contact, then resume only the approved audience. Inspect waiting E1b results and recovery tasks. For rollback, pause, set `slackInviteInE1b` to `false`, then reduce or disable post-form enrollment if necessary. The reverse configuration guard enforces this order so future paid welcomes retain their invitation. Existing audience allowances and receipts remain unchanged; review any pending post-form customers individually. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.