fundingmachine.slack.com to myfundingmachine.slack.com. Owners join the support
workspace as members and no longer need Slack Pro to communicate with Funding Machine.
Their business may still need a paid plan for its own workspace.
Migration uses a separate assignment registry. It does not restart onboarding,
change subscriptions, or send a new-customer payment welcome. Automatic assignment
requires the migration code to be deployed and its separate enable switch to be on;
preparing this workflow does not itself activate production automation.
Choose eligible owners
Use the Operations account’s Retention opportunity as the primary source of truth. Check the contact, opportunity stage, status, tags, custom fields and saved Slack ID. An open opportunity with a conflicting cancellation tag needs review. Cross-check Stripe ownership subscriptions, including relevant older billing accounts. A canceled subscription can have a current replacement. A current credit-pull or other add-on subscription does not establish an active Funding Machine ownership account. Hold unresolved billing discrepancies, paused or past-due accounts, uncertain identity matches and Transitioned to CEO Partner records for a decision. Match by exact account/contact identifiers, email and channel evidence. Names and business names help locate candidates but do not authorize private-channel access. Keep the Operations opportunity and the owner’s product Location distinct.Check for an existing channel
Inspect the saved CRM channel ID, the new workspace and current membership before creating anything. FM Bot can see only private channels it has joined. A successful search returning no bot-visible match is not a complete duplicate check: inspect staff-visible private channels as well and record the evidence and time checked. If a matching channel already exists, verify its business and workspace, adopt its ID and repair missing bot or staff membership within the approved scope. Do not create a replacement just because FM Bot cannot see it. Multiple old channels for one owner must resolve to one destination before preparation proceeds. Channels follow the existing workspace naming and staff rules:fm-{first-name}-{last-name}-{company-name}, omitting the company when unavailable.
Names alone never establish that a channel belongs to an owner.
Company enrichment is best-effort: use the live CRM contact’s nonblank company, or
fresh, explicitly reviewed company evidence from that exact contact or the linked
product Location’s business.name / name. The CLI does not fetch the product
Location’s business; crm_location evidence records an operator’s scoped live
review. Never infer a business from an email domain or a fuzzy old channel match.
If evidence is missing, stale, scoped to another record, contradictory or malformed,
or the company would produce an invalid or overlong Slack name, preparation uses
fm-{first-name}-{last-name} and records a company-name review warning. Invalid
first or last names still hold preparation. Eligibility, identity, duplicate and
uncertain-write checks remain required.
An existing verified destination retains its live name. A naming mismatch is a
separate cleanup warning; it does not deny support or cause replacement creation.
Renaming needs explicit authorization for the exact channel and a live readback;
this CLI never renames. Reuse that channel’s ID and ledger after an authorized rename.
Prepare a batch before sending messages
Begin with a dry run of up to 25 approved owners. Keep held records separate and review the proposed changes. For every included owner, finish all of these steps before sending the batch’s migration announcements:- Reserve the exact migration identity before any provider writes. This prevents onboarding from preparing the same owner concurrently. A saved creation-attempt marker prevents a lost local receipt from creating a second channel.
- Verify or create the private destination channel using FM Bot and pin its ID to the reservation. A reviewed existing channel can retain its current name.
- Confirm FM Bot and the configured internal support staff are members.
- Save the new Slack Channel ID on the exact Operations Retention opportunity and confirm it by reading it back. Keep the previous ID in the migration receipt.
- Enroll the approved owner email, product Location, opportunity and destination. Enrollment also updates the app’s saved Location-to-channel mapping so support features use the new channel. Confirm that assignment is unpaused and the deployed worker is enabled; a preparing reservation is not an enrolled assignment.
- Confirm the approved training link, workspace invitation and announcement text.
Automatic assignment and welcome
The worker uses the exact approved email to find an active human member of the new workspace. Once that person joins the workspace, it adds them to the reserved private channel. Events and recovery checks re-read current membership rather than relying on event order. A different email needs staff identity review; matching a display name is insufficient. After channel membership is confirmed, FM Bot sends one welcome specifically for an existing owner moving workspaces. An owner who already belongs to the channel uses the same welcome path. The saved welcome receipt prevents a retry from intentionally sending another welcome; an uncertain send needs delivery verification. The worker does not create channels, change CRM opportunity fields, change billing or archive old channels. Those remain explicit migration steps. Connected migration assignments use the existing support-message handling with the same verified private-channel and member checks. Preparing, waiting, paused or review states do not grant automated support-message access. Resolve a welcome-delivery review before treating the automated support flow as connected. Verified staff replies can still stop an existing automated support response during a pause, review or reconnect, provided its account and channel mapping remain valid.Confirm the move and archive
Check the correct private destination’s live roster. An active human from the owner’s business can establish that the migration succeeded, even when a verified teammate joins on the owner’s behalf. Staff, bots and deactivated accounts do not count. Staff may use several email addresses or workspace identities, so use the verified staff roster and known aliases. A teammate’s presence does not authorize substituting their email for the primary owner in the assignment registry. Resolve remaining eligibility and identity holds before archiving. Review the old channel for a previous unarchive or another reason to keep it open. Archive only the exact old channel covered by the approved move, then read back its archived state.Track verified outcomes
Keep one row per owner/channel mapping, with these milestones separately recorded:
A proposed next action is not a completed milestone. Historical checkboxes and
message-history exports do not establish current membership or archive state.
If the tracker update fails after a provider write, preserve the receipt and repair
the tracker before retrying the provider action.
Manifest example
Keep the manifest outside the repository. This schema-valid example contains only synthetic identities and intentionally old review timestamps. Replace every identity, record the actual authorization and refresh the evidence before use; it is not a live batch or approval to act.locationId is the owner’s product Location. contactId and opportunityId belong
to the Operations account. previousChannelId is the old workspace channel to retain
in the migration history. expectedCrmChannelId records the value actually read from
the opportunity: use "" for a confirmed blank field, or the exact saved channel ID.
If omitted, it defaults to previousChannelId; do not use that default when the CRM
field is blank. The optional channelId adopts an already verified destination.
billing.status accepts active or trialing; a trial does not prove an invoice was
paid. Billing and staff-visible duplicate-review evidence must be refreshed within
24 hours. A missing duplicate review may appear in a dry-run report, but blocks live
preparation. Do not infer private-channel absence from FM Bot’s search alone.
companyReview is optional enrichment, separate from access authorization. Its
source is crm_contact with sourceId equal to the exact contactId, or
crm_location with sourceId equal to the exact product locationId. Record the
verified company name, checkedAt, reviewedBy and descriptive evidence.
Reviews expire after 24 hours. A contact-source review must still match the live
contact company; a Location review conflicting with a nonblank live contact company
falls back with a warning for review. With no review, a nonblank live contact company
is used directly. Unusable review evidence falls back to the personal name even if
the contact has a company, so contradictions are not silently accepted.
Use 1–25 unique owners per manifest. Reuse the batch and receipts to resume the same
identities. Review timestamps can be refreshed; changes to the actual owner/channel
mapping require reconciliation with the saved receipts before continuing.
Adding, correcting or refreshing company evidence does not change the identity hash
or require a new ledger. Legacy manifests without company review remain usable.
Tool controls and recovery
The repository’sscripts/onboarding/slack-migration.ts provides preflight,
prepare, enroll, status, pause, resume and reconnect. It defaults to a dry
run. Batch commands use an external --manifest; applied preparation and enrollment
also require an external --receipts path. Live writes require both --apply and
--prod; omitting --apply keeps the command read-only. Inspect --help and the manifest
contract before running a batch. A dry run does not save an assignment or enable
background processing.
SLACK_MIGRATION_ASSIGNMENT_ENABLED=true is the separate worker switch and is off
by default. It also requires the existing support-workspace configuration to be
enabled. Deployment and production activation require approval for the named
environment; migration approval does not authorize a deployment. Existing onboarding
switches are not a substitute for the migration switch.
Read status before using the controls and pass the current assignment --id,
--revision and a --reason. Pause stops future assignment writes while keeping
existing channel access; a provider request already dispatched may finish. Resume revalidates the saved assignment before continuing. Reconnect is for
an explicitly approved restoration after a member was removed; it preserves the
welcome receipt. Do not use resume to override a removal or a changed identity.
On a timeout or unknown outcome, inspect the saved channel, opportunity, assignment
and message receipt before retrying. Reuse the original channel and stop on conflicting
mappings. Never remove a welcome receipt to force another send.
A preparing reservation keeps ownership even after a failed run. If channel creation
was attempted without a confirmed ID, recover that exact channel through Slack before
continuing; do not clear the server marker or switch receipt files to retry creation.
Pause/resume preserves preparation state. Reconnect applies only after enrollment.
Receipts pin requestedName before provider mutations and retain it on retry, even
when better company evidence appears later. name records the live Slack readback;
namingWarnings records enrichment and cleanup work. A legacy creation receipt’s
saved name supplies the original intent when no requestedName exists. Preserve
creation-attempt markers, recovered channel IDs and welcome receipts. Unknown
creation still requires recovery of the original ID; editing company evidence or
switching ledgers cannot authorize a second creation. A new proposed company suffix
is a separate rename candidate, never a reason to recreate or abandon the ledger.
Keep manifests, receipts and customer exports outside the repository. Store credentials
in the approved environment, not command arguments, spreadsheets, screenshots or Git.