> ## 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 workspace

> Review active clients, update CRM fields, and complete staff stage reviews.

The staff **Onboarding** workspace shows open clients from **New — Paid** through
**Final QA Check**. Live clients leave this queue. Access requires a staff account;
editing also requires the workspace and account rollout settings to be enabled.

**Admin → Onboarding** (`/admin/onboarding`) is the primary place to update required checks, shared blockers, attendance, identity review, provider updates, and account configuration. Select a client for a concise summary, current call and quick note. Open a task row for its controls, or **Actions** for owner, hold and stage shortcuts. The Operator’s **Onboarding & Setup** page contains their own actions and progress; staff controls do not appear there.

See [Onboarding connections](/staff/onboarding-connections) for the source of each
field, calendar ownership and current rollout limitations. The September 29 audit
found calendar mappings unsaved and general staff CRM writes disabled; enabled KYC
does not enable those separate controls.

See [Focused onboarding workspace](/staff/onboarding-workspace) for the full-screen layout,
account setup controls and saving across sections.

## Find the next client

The counted filter tabs above the queue show all clients, attention, assigned clients,
holds, calls today, and readiness to advance. Select a tab to filter the queue.

Use **Needs attention**, **My clients**, **Calls today**, or **On hold**. Search by
client, linked Location or owner. The Location name appears beneath each client name. Open **Filters** to combine stage, assigned owner (including Unassigned),
Last Active, and Last Credit Pull. Activity filters support within seven days, older than
seven or thirty days, no recorded activity, and unavailable data. **Clear filters** resets
the search and filters. Sort by attention, longest in stage, or either activity date.
Switch between the compact table and pipeline
board. Counts describe loaded clients; use **Load more clients** to include later pages.
The control disappears when CRM pagination metadata proves the final page has been loaded.
If the CRM does not provide enough information to confirm the end, the control may remain available so you can check for later records.

Yellow tags identify missing information, KYC reviews and holds needing review.
Green **Ready for QA** means all required setup outcomes are complete and the shared blocker is resolved; staff still perform the final review. **Missing info** lists what is recorded in the CRM Missing Info
field; its tag turns red when a call is within 24 hours. It does not infer other
call preparation tasks. Call times, including Today and Tomorrow, use each client Location’s business timezone. If the Location timezone is unavailable or invalid, the display explicitly uses UTC.
Calls reflect the latest account booking check, so refresh account setup when needed.

**Last Active** is reserved for verified customer activity. Collection is deferred while
we establish reliable customer identity for this login surface, so accounts without
verified activity show **No recorded activity**. Legacy login timestamps are kept
separately and do not fill this column. **Last Credit
Pull** shows the creation date of the latest successful, non-sample report. Failed
and pending requests do not update it. Hover a recorded date for the exact timestamp.
**No recorded activity** means the linked account has no matching event; **Unavailable**
means the account mapping could not be verified. Neither is automatically a blocker.
On smaller screens, client cards show the two activity dates together.

**Ready to advance** shows clients whose recorded stage requirements are met. Staff
must still review the transition and explicitly approve Final QA before moving Live.

## Update a client

The shared readiness panel counts every required outcome, including Identity when
enabled. Its count can be nine or ten; reopened KYC is no longer complete. The
Operator view hides the partner page and website checks from its count, but it only
reports setup complete once all of them are done. Final QA uses this shared readiness, while the existing stage
requirements and explicit staff approval remain in place.

Use the task’s inline editor and the staff update form to explain
the next action and choose Operator, Funding Machine team, or External provider.
An optional calendar date sets the team's next review, not a completion promise.
Save with **Save team update**. These fields are visible to the Operator. Keep
private case details in CRM notes. Clear the text and save to resolve the blocker;
enter a new update to reopen it. Saves are revision-checked and audited.

The shared blocker prevents readiness for final approval until resolved. It is
separate from CRM Missing Info and does not create tasks, send messages, or change
CRM fields. The existing opportunity owner stays responsible for follow-up;
choosing External provider does not assign a named staff member. Older updates
retain their original meaning of waiting on the Operator unless staff changes it.

Select a client to open the [stage-aware sidebar](/staff/onboarding-sidebar). It shows the
stage, owner, KYC status, setup progress and next action. New — Paid shows form and kickoff
details. Compliance puts its checkboxes and Slack channel first. Setup In Progress shows
the setup checklist, website status, FM calls and technical-call dates. Final QA shows
readiness checks and explicit staff approval. **All requirements** reveals all stages’ CRM fields, including owner, Missing Info, Hold Status and Hold Until. **View full client** adds room without changing the active stage. KYC is read-only;
open **Identity verification** to review it. **Calls & notes** contains
all call slots, manual technical-call completion dates, contact details, tasks and notes.
**Actions** focuses Change owner, Hold / resume, or Review stage.

On wide screens the sidebar sits beside the queue; on narrower screens it opens as
an overlay. The expand arrow opens the full workspace; the collapse arrow returns to
the compact view. Expanding, collapsing and resizing preserve unsaved drafts. The
save footer appears only while edits are pending. Account setup forms and notes use
their own save buttons; **Save** submits CRM checklist or technical attendance changes.
Close the panel to return to the filtered queue. Unsaved changes prompt you to keep
editing or discard; **Discard** resets field and note drafts. Account setup drafts
must be saved or discarded in their own forms.

Completion dates represent confirmed attendance; a call ending does not establish attendance.

**Save** automatically syncs changed fields to CRM and checks the result, keeping
the current client open. The queue refreshes when you
return to the browser or every five minutes while visible, unless you have a draft.
Use **Open in CRM** whenever you need the full record.

Opening a client only reads: it shows the last confirmed business website and **1. MAIN Apply For Funding Form**
and never writes to CRM. **Refresh links** reads them fresh after the technical call.
The form initially uses a working default-domain link with **Branding pending**. Once the
Location has a branded domain, its exact hostname is used with `/widget/form/{formId}`.
The separate **FM Processing Application** is never selected here. Duplicate intake names
use a consistent selection, retain the previous valid form ID, and show a staff notice.

Refreshed links sync to the opportunity through the existing audited save when CRM writes
are enabled. With writes disabled, discovery can update account setup but the opportunity
stays unchanged. Failures retain confirmed links and show an error; an uncertain CRM save
must be reconciled before retrying. The website comes from the CRM Location’s business settings; there is no separate onboarding URL override. Correct the source in CRM business settings, then use **Refresh links**. A successful read of a valid website completes the automatic website check. A successful empty or invalid result clears the website and reopens its check; a failed business-profile read preserves the last confirmed website and readiness with a warning. Form lookup failures do not prevent a successful business-profile read from updating the website.
The website and direct form link need no staff verification; a working default form link
is valid while branding is pending. Expand **Partner application page** for the separate
check: the technical team connects the `apply.` subdomain to the funnel with the funding
application embedded for affiliate/partner referrals. In the client panel, enter its
HTTPS URL and select **Verify page** after checking routing and policy links. Save
without verifying for a draft; **Reopen verification** undoes confirmation. Changing or
clearing this URL reopens its check. These controls save the local checklist only and do
not change the CRM stage. The funnel stays staff-only and remains one of the nine required
outcomes. Automatic form-link refreshes preserve its verification. Legacy saved apply
URLs are retained separately when the direct form is first discovered.

Select **Actions → Review stage** to open stage review. The required checks and explicit
confirmation still apply; selecting the control does not move the client.
Changing CRM fields does not mark the Operator's setup outcomes complete.

If another person changed one of your edited fields, refresh and review your draft
before saving again. An uncertain save stays blocked until **Check save result**
confirms it. If it remains unresolved, wait five minutes and compare the original
values in CRM. The review control requires an explanation (10–500 characters) before
another save is allowed. If someone changed the same fields in CRM after your save, the
values match neither your original nor your saved values and **Check save result** says so;
after five minutes you can still release the save with a note describing what you found.
The release is audited with your note and the CRM values observed at that moment.

## Account setup administration

Select a client in **Admin → Onboarding**. Open a task row to review its evidence or edit it directly in the side card. **View full client** adds room while preserving the active stage and editor. **All requirements** reveals earlier and future CRM fields; **Troubleshooting** holds mapping, call assignments and recovery. The header identifies both the business/Location and the verified Operations contact; no separate browser tab is needed. Use it for verified contact mapping, staff-owned outcomes, identity evidence and recovery, shared blockers, provider updates, Slack matching, and appointment or phone recovery. These controls are not part of the Operator onboarding view. If the client mapping needs repair, this section exposes only contact mapping until it matches the opportunity. For a missing Product Location ID, use **Connect the SaaS account** to derive the contact and opportunity links from the subscription. Conflicting mappings still require review. See [automatic account linking](/staff/onboarding-account-linking) for prerequisites, retries and exceptions. An account outside the Operations agency shows its account link as needing review; Provider checks require explicit refresh and their existing permissions.

For a Location already Live or without an open onboarding opportunity, use **Admin → Locations → the Location → Onboarding**. It provides the same staff controls scoped directly to that account, without requiring a queue entry or searching again. Admin → Onboarding remains the primary workspace for active onboarding.

Location 360 and client health onboarding indicators use the current account setup checklist, including identity when required. They show **Not started** when no setup progress exists, even with an active subscription. The dashboard percentage uses all required setup outcomes; the completion date stays empty because the checklist does not record a completion timestamp.

**Discard setup edits** resets only unsaved account-setup fields to their current saved values. It leaves saved changes and other client drafts intact. Use it after abandoning a reschedule or any other setup edit. If another person saved this client’s account setup after you started editing, your save is rejected with “Setup changed in another session” instead of replacing their change. Choose **Discard setup edits** to load their saved values, then re-enter your edit.

The same account panel retains delivery-path selection, partner application verification and reopening (verification needs only a saved partner page URL; the delivery path does not block it), and manual confirmation or reopening of staff-owned setup outcomes. Website readiness remains automatic from CRM business settings. Identity evidence, recovery, and reopening still use the existing checks and audit requirements. Use the [identity guide](/operators/getting-started/identity-verification) for the customer verification flow.

### Link an existing Stripe verification

Use **Link an existing Stripe verification** in the identity controls when the Operator already verified with Stripe outside this flow, for example through a one-off Dashboard verification. Copy the page URL from the Stripe Dashboard address bar, either the verification session (`https://dashboard.stripe.com/identity/verification-sessions/vs_…`) or the Stripe customer (`https://dashboard.stripe.com/customers/cus_…`). An account segment (`/acct_…/`) and a test-mode segment (`/test/`) are accepted when they match the configured identity account and environment. Other links, query strings, and connected-account pages are refused.

A customer link works only when exactly one verified session is attached to that Stripe customer. If there are none or several, paste the session link instead. Sessions created without a customer do not appear under a customer.

The app links a verified session whose report verified both the photo ID and the selfie. First name and full surname normally match both the reviewed SaaS subscription cardholder and the current Operations contact; middle names may differ or be omitted without manual review. For nicknames or other name differences, staff can [review and confirm the same person with a recorded reason](/staff/identity-name-review). For an earlier document-only verification that did not require a selfie, follow [Accept an earlier identity verification](/staff/legacy-identity-verification).

Linking is unavailable while the Operator's own verification is processing or unresolved, or while account links need review. If another account already uses the same session, the app shows that account's name and asks you to confirm before linking. On success, the app sets the CRM **KYC Verified** field to Verified, confirms the CRM save, and records who linked it and the URL in the audit log. Verified names and documents stay in Stripe.

To undo a link, use **Reopen verification**. It sets CRM KYC back to Incomplete and detaches the linked session without canceling it in Stripe.

The CRM **KYC Verified** field remains the source of truth. After **Check status**, the Operator's step shows complete when the CRM says Verified, and shows *Your team is reviewing your identity verification.* when a verified step no longer matches the CRM; staff then see **Reopen verification**. An unresolved account-link review still holds the step even when the CRM says Verified. Checking status never changes the CRM field.

Use **Admin → Settings → Onboarding** for the shared kickoff and two FM calendar selections from the operations CRM account.

Operators now join the shared My Funding Machine Support workspace with free Slack accounts. Setup creates their private support channel, saves the returned ID to the exact CRM opportunity, and adds the approved Operator after matching the verified onboarding email. Follow the [workspace setup guide](/staff/slack-workspace) for deployment, bot installation, invitation and activation gates.

Use **Slack support workspace** to refresh connection status, pause/resume automatic setup, or approve a reviewed reconnect. A removed member is never silently re-added. If Slack cannot be read, the status stays **Unable to verify**; provider errors do not count as a confirmed departure.

To adopt a private channel already created in that workspace, invite FM Bot, then enter its channel link or ID in Compliance before automatic setup reserves a channel. Existing channel membership must contain only the approved Operator and configured staff. The app validates the channel and confirms the CRM save. A reserved mapping cannot be replaced or cleared there; pause setup and escalate a mapping correction. Clearing an unreserved link never deletes the actual Slack channel. Check an uncertain save before retrying.

For an unresolved phone purchase, check the Location’s number inventory and billing. If it succeeded, refresh setup to confirm ownership. If you establish that it did not complete, use **Review phone purchase** in the client panel’s account setup controls, record your evidence, and allow a new search. This control requires at least five minutes since submission and records an internal audit entry.

When slots share a calendar, refresh setup and use **Choose matched appointment** to assign a distinct booking to each slot. Dates and statuses help identify each booking; appointments already used by another slot are disabled. An exact CRM appointment ID can also be entered. Save the call and refresh to verify it. Ambiguous appointments need your attention; the app does not guess which call belongs to which step. Use **Onboarding search start** for the verified onboarding/payment date. Leaving it blank searches the past 180 days and next 90 days. Changing the period keeps explicit assignments; clear or replace those separately when appropriate. An incomplete provider search preserves last-known data with a warning. Manual call overrides require a reason and can be cleared to resume syncing. Technical calls can have manually entered dates until their external booking source is connected. Date/time inputs use the Location’s business timezone. Ambiguous or nonexistent clock times during daylight-saving changes must be corrected before saving.

A cancelled or no-show booking is replaced automatically by the client’s single active rebooking on the same calendar, unless staff assigned that slot’s appointment or the slot shares its calendar. If a staff-assigned appointment is cancelled or marked no-show and the client has rebooked on that calendar, the call shows **Verify booking** until you assign the new booking with **Choose matched appointment**. The app never switches it automatically. A cancelled booking with no rebooking still shows as cancelled. If the client already attended a call on that calendar and a later booking was cancelled, the call shows the attended one as completed.

Use **Calls & notes → Calls & attendance** in the full workspace to record or correct a synced kickoff or FM call’s CRM status. A manual call override changes only the onboarding display; clear it before updating the CRM appointment. Operators cannot record attendance or use staff status controls. The appointment’s **Manage** disclosure can reschedule or cancel an upcoming booking; its attendance control records the separate attendance decision. Once a client is Live or closed, correct attendance in the CRM directly. Staff appointment changes in either place require the default-off CRM editing setting.

If an appointment change remains unresolved, check the CRM appointment and its
notification history. After at least five minutes, **Review an unresolved change**
lets staff record that review and allow another change. This does not undo or resend
the original request. Refresh the appointment before editing again. Disabling the
onboarding Labs flag prevents new submissions but cannot undo one already sent.

Account setup controls do not change subscriptions or commercial onboarding stages. Use the client panel’s separate stage review for approved CRM transitions. Zoho migration remains a separate tool.

## Change stage

Save field edits first. Forward moves require **Active** hold status (a blank Hold Status counts as
Active) and move one stage at a time. Moving backward requires a reason.

| Transition | Required evidence |
| - | - |
| New — Paid → Compliance | Submitted onboarding form and a recently verified kickoff booking |
| Compliance → Setup In Progress | Confirmed kickoff attendance, Payment Verified, Slack Joined and Skool Joined, KYC Verified |
| Setup In Progress → Final QA Check | Both technical calls complete; FM onboarding 2 completion or staff waiver date recorded; website Published |
| Final QA Check → Live — Onboarded | All required setup outcomes complete (including Identity when enabled), no shared blocker, valid account links synced to CRM, no Missing Info, explicit staff QA approval |

Each unmet requirement lists what is wrong, such as an empty CRM Website URL, an open
setup outcome or the shared team update still being set, with a link to the control that
fixes it. The stage review badge shows **Ready** or how many requirements remain. When
the move button is unavailable for another reason, such as unsaved edits, the reason
appears beneath it. If CRM links are empty or differ from account setup, use **Refresh
links**; **Refresh setup** in Troubleshooting does not write links to CRM.

Phone setup and texting approval are optional for these transitions. Stage changes
can trigger the existing CRM onboarding process. The existing process owns the
retention handoff; this workspace does not create retention records.

If the automated Retention handoff is blocked, verify that the Retention card's
**Product Location ID** matches the onboarding account. A shared contact alone
does not establish that match. Missing or conflicting mappings require review
before the automation can finish onboarding.

## Client context and CRM checklist alignment

Open **Calls & notes → Client context · Notes & tasks** to load the selected client’s contact details,
latest staff/workflow notes (including onboarding answers recorded in notes), and
outstanding tasks with their assigned owner and due date. Overdue tasks are highlighted.
Context loads on demand and has its own refresh, which preserves field and note drafts.
Expand **Add note**, then use **Save note to CRM** to append a note to the client’s CRM contact.
Notes use your verified CRM staff identity and support up to 5,000 characters. The app reads
back the note before confirming success. Existing notes and tasks can be changed using
**Manage existing notes and tasks in CRM**. The panel
shows up to 50 latest notes and 50 outstanding tasks ordered by due date, with a notice
when more exist. A failed read is shown as unavailable, never as an empty history.

**Calls & attendance** has status dropdowns for linked kickoff, FM onboarding 1 and
FM onboarding 2 appointments: **Confirmed**, **Showed**, **No show**, **Cancelled**, and
**Invalid**. Changes save immediately to the verified CRM appointment; CRM notification
settings apply. **Showed** displays the actual appointment date beside the status and
syncs the corresponding opportunity completion date. Changing it back clears that date.
FM onboarding 1 has no separate opportunity completion-date field. Technical calls 1
and 2 remain manual date fields in **Calls & notes** because their bookings are managed separately.

For an unnecessary FM onboarding 2 follow-up, select **Not needed**. This records the
server's current date as the staff waiver date and satisfies only that milestone. It
does not cancel a booked appointment or report attendance. Select **Remove override ·
use CRM status** to restore the linked appointment's status and matching date.

An uncertain appointment change exposes **Check appointment result** and blocks another
status change. A separate opportunity save can fail after the appointment succeeds;
review any pending CRM save, then use **Sync completion date** to repair the date without
resending the appointment change. Existing manual CRM dates remain visible for review
when they differ; an explicit status change or date sync replaces that call's date.
Save other field/note drafts before changing call status.

This section also shows meeting links, hosts when available, and booking check time. Use **Refresh bookings** to check the provider’s booking status. **Manage** beside the relevant appointment opens rescheduling and cancellation. **Troubleshooting** contains call assignments and corrections. When a call has no linked booking, its card explains why and **Open call corrections** jumps to Troubleshooting. Unsaved drafts stay in
place; save or discard them before submitting a different kind of change. Completion dates still require confirmed attendance.

**Missing Info** follows the CRM field’s configured choices (multiple choice, single choice,
or legacy text). Selected choices drive attention and the Final QA missing-information check.
**Blocked** is editable when that CRM field is configured, except where automatic
progression maintains it from Missing Info; there, update Missing Info instead. **Tech Calls Complete**,
**A2P Verified**, and **Onboarding Completed Date** show the opportunity’s recorded values;
they are not inferred from notes and are not additional required setup outcomes.

Setup groups the work into **Call completion**, **Setup checklist**, and **Business links**.
The checklist shows **Verified in account** beside a verified partner page, sending email,
or an owned phone number checked within five minutes. Check the appropriate item, then
use **Save**. These hints never automatically select or clear items, mark local outcomes
complete, treat phone opt-out as purchased, or infer attendance from elapsed time.
Application Page Connected is displayed as **Partner application page connected**;
the underlying CRM choice is unchanged. **Refresh links** discovers current business links
and syncs them when enabled. **Retry sync** appears only after a failed link save;
an uncertain save must first be checked and resolved through **Check save result**.
Saving, refreshing, and verifying keep expanded sections open and preserve your position
in the client panel.
The technical team's partner page controls start collapsed, with verification/unsaved status
visible in the summary. **Additional status** contains technical-call and optional texting
indicators. Neither creates another required checklist.

The workspace accepts the existing hyphenated New - Paid and Live - Onboarded CRM stage
names without renaming stages. Ambiguous stages still require configuration review.
A Product Location ID pointing at the operations account is flagged and blocked from
account setup reads and writes. Staff must correct the client mapping through the existing
CRM/account setup process; the workspace never guesses a replacement Location.
A client whose CRM onboarding fields can't be read shows **CRM record needs review**
instead; the rest of the queue still loads. Fix the record's field values in the CRM and
refresh. Its onboarding fields can't be edited until then, and its account setup controls
stay available.

### Saving notes

Note creation uses the same default-off CRM editing setting and verified account mapping
as opportunity edits. Saving a note keeps any field changes you have drafted; save or discard
the note before saving fields or verifying the affiliate funnel. Closing or switching clients
warns about an unsaved note. Context refresh preserves the draft.

A rejected or interrupted save keeps the draft. **Retry note save** reuses the original
request to avoid duplicate posts. If the provider result remains uncertain, use **Check note
sync**; it only reads CRM and never posts another note. Other note submissions for that
contact remain blocked until the result is resolved. After five minutes, staff can review
CRM and record evidence that the note is absent before allowing a new attempt. The app
rechecks CRM before releasing the attempt. Notes do not complete checklist items or confirm
attendance. Sync auditing stores request IDs, author, timestamps, a content hash and result
metadata, not another copy of the note body.

### Automatic progression

The [paid-customer rollout](/staff/onboarding-progression) uses verified payment
and active sending membership to select new customers automatically. Existing customers
and compute-only pilots remain excluded. The same eligibility appears in **Change stage**
and is rechecked before automatic CRM saves.

When enabled for an account, **Save** also checks whether the client qualifies for the
next stage. A background check every 15 minutes picks up changes made directly in CRM
while this workspace is closed. Each check advances at most one stage. The same approved
requirements apply, and automation stops at **Final QA Check**. Going Live still requires
staff QA approval. Holds, MIA, unresolved saves, disabled setup, and invalid mappings block
automatic progression. Clearing a requirement changes its checklist status; it never moves
a client backward automatically.

**Change stage** shows whether automatic progression is enabled and provides Pause/Resume.
A backward move in this workspace pauses progression automatically. A backward move made
in CRM also pauses it once detected against a previously observed stage. Resume after the
reason for moving backward has been resolved. Moving backward before the first automatic
observation cannot be detected from stage history the app has not collected.

For enabled accounts, the same process maintains **Blocked** from Missing Info and
**Tech Calls Complete** from both confirmed technical-call dates, including clearing the
helper when its inputs are cleared. Blocked is read-only here while automatically managed.
It also synchronizes the existing CRM credit-activity date from successful, non-sample
credit reports. Customer-activity collection is deferred; its date remains unchanged
without verified source data. Dates are written only when their value changes;
unknown dates stay empty. No individual activity events are copied to CRM.

The CRM board rules and these fields are separate. Call-completion tags remain visible
while the completion date exists. Active requires both recent login and recent credit
usage; At Risk uses the existing inactivity thresholds. A2P, billing and Slack-plan status
retain their existing owners and are not inferred from other setup fields.

When automatic synchronization is enabled for your account, verified Slack connection and
business-phone inventory update their matching CRM checklist choices. Other choices remain
as entered by your team. An unavailable check keeps the previous value; a confirmed
Slack disconnection or empty phone inventory clears the matching choice. Phone and texting
approval remain optional.

Confirmed kickoff attendance and technical-call records with an actual start time can fill
empty completion dates. Technical calls still require your team's attendance confirmation.
The sync never treats a call merely ending as attendance, and never replaces a manually
entered date. If you correct attendance, it can revise or clear dates it previously populated.
Completion dates use UTC. Account checks are reconciled after a staff field save or on the
15-minute background check. The single onboarding-call completion date represents
the FM onboarding 2 milestone. Confirmed FM onboarding 2 attendance can fill it automatically;
FM onboarding 1 alone cannot. If the client does not need a follow-up call, select **Not needed** in Calls & attendance.
The staff waiver date is recorded automatically without changing the appointment’s attendance status. All other readiness requirements still apply,
and going Live still requires final staff QA approval.

### Phone and Slack connection checks

Use **Admin → Onboarding** to review setup exceptions. An unprovisioned phone system
shows guidance to finish setup in CRM Phone Settings; do not treat that response as
confirmed empty inventory or a completed phone step. Existing numbers remain visible
when a refresh cannot confirm them.

Slack checks accept an exhausted CRM page even when the provider retains a next-page
URL, but only when the first-page marker and exact total prove the search is complete.
Onboarding and Retention may both carry the same channel for the same account; the
check uses the unique Onboarding source. See [Slack opportunity mapping](/staff/slack-opportunity-mapping).
Partial or conflicting results still require review. If no channel is mapped after a
successful search, review **Compliance → Slack channel link or ID** in Admin → Onboarding
and review the **Slack support workspace** task. Legacy source selection remains under **Troubleshooting** only when the workspace flow is disabled.
Only an opportunity whose **Product Location ID** equals the account can supply its Slack
channel; a blank or different value never does. If the check asks you to set or check the
Product Location ID, fix that field and refresh. Existing channel links are kept meanwhile.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.