Skip to main content
Open Admin → Settings → Onboarding. Only authorized staff can read or change these settings. Calendar and invitation saves are independent; changing the community link does not change calls, client checklists or private support access.

​
Publish a Never expires invitation

  1. In the support Slack workspace, open Invite people → Edit link settings and select Never expires. Copy the resulting shared invitation.
  2. Open the link and verify the correct support workspace. Paste it into Slack community invitation, confirm the workspace and Never expires, choose the alert channel and save.
  3. In Slack’s Admin → Workspace settings → People → Invitations → Invite links, read how many people joined through this exact link. Expand Record an invitation check in the app, enter that count and record the verified result.
Only links confirmed as Never expires are supported. There is no expiry date, renewal lead time or calendar-based replacement. Previously saved and deployment invitations need this one-time confirmation before Operators can use them. The app also matches the invitation’s workspace to the support bot before publishing. Every Operator’s Join button retrieves the current approved link on click, so already-open pages pick up replacements. A stale save is rejected; reload before trying again. Clearing the URL removes the invitation without falling back to an old deployment URL.

​
Capacity and alerts

Slack permits up to 400 people per shared link. The default threshold is 350, leaving room to replace it before it fills. See Slack’s invitation limits. The app counts distinct new human workspace members from signed Slack join events. Retries count once, channel joins do not count, and unrelated settings saves do not reset the counter. Pausing the onboarding button does not stop counting people who join through a previously shared link. Publishing a different link starts a new count; recording Slack’s actual use count establishes a fresh baseline. Existing member identities are not counted again after a replacement. This is a new-member estimate, not a count of repeat admissions; Slack’s per-link usage remains the source for replacement decisions. Estimated uses combines that baseline with subsequent new workspace members. Slack’s join event does not identify the invitation used: other invitations may overcount, and missed events may undercount. A weekly browser check reconciles the estimate with Slack’s actual per-link count. If new members arrive while staff record a count, reload and check Slack again before saving. The estimate triggers a capacity warning; it never disables a working link on its own. A confirmed count of 400, or an explicitly broken/deactivated link, withholds the invitation from Operators until a working replacement is published. The app evaluates capacity and availability every hour. Alerts repeat at most daily for the same issue; failed deliveries retry hourly. Alert needs attention shows failures, and Last alert accepted by Slack records an acknowledged send. No invitation URL or client information is included in alerts.

​
Weekly check and replacement

The weekly runner checks Slack’s actual count and availability. It replaces the link only when that count reaches the configured threshold or Slack confirms the link no longer works. It never rotates a link because it is old. A new link must also be set to Never expires, verified, saved, and have its actual count recorded. Keep the runner’s computer available with Slack and app admin sessions signed in. Enabling the permission does not create a runner. Turning it off hands replacement to staff while alerts continue. A network or sign-in problem preserves the last confirmed availability and requests review. It cannot revive a link previously confirmed broken or exhausted. If Slack no longer offers Never expires, stop and ask staff; do not publish an expiring replacement. Private support memberships are managed separately.

​
Calendars

Choose kickoff, FM1 and FM2 calendars, then Save calendars. Operators see their own matched appointments. Where two call types share a calendar, assign distinct appointment IDs in that Location’s Onboarding tab. Technical calls remain manual until their booking source is connected. Enable onboarding per Location in Labs.