Workspace Setup
Paid community Slack workspace setup — pre-launch decision reference card
Five decisions you must make before the first invite goes out, and six configuration steps that determine whether a new member’s first login creates a first post or a cancelled subscription. This reference card covers the account tier matrix, workspace URL naming rules, minimum channel structure sequence, two permission baseline configuration cards, export and retention settings, and a five-point pre-launch verification test. The narrative companion post (Paid community Slack workspace setup) explains the consequences of getting each decision wrong. This page is for the operator who is actually setting up the workspace now and needs the exact admin paths and decision criteria, not the explanatory context.
TL;DR
Before sending the first invite: decide account tier (Pro is the right starting point for a paid community; Free has gating that harms activation; Business+ is premature until 500+ members), set the workspace URL to match your brand domain (it cannot be changed without breaking existing bookmarks), create the six-channel minimum structure in the correct order, apply the three permission changes (default channels restricted to two, @channel restricted to admins, #start-here operator-only posting), configure export settings to Workspace Owners only, and run the five-point verification test. Total one-time setup time: 90–120 minutes. Every decision except workspace URL can be changed post-launch, but the URL change creates broken bookmarks for all existing members — that one is a do-now-or-regret.
Pre-launch decision checklist
Five decisions with different reversibility profiles. The “Risk if skipped” column describes the consequence of accepting the Slack default on each decision — not a hypothetical risk, but the specific failure pattern that appears in communities that launch without addressing that item. The Do now or regret column marks the one decision that cannot be undone post-launch without a disruptive consequence for existing members.
| Decision | Do-now-or-regret | Can change post-launch? | Slack default if skipped | Risk level |
|---|---|---|---|---|
| Account tier | No — can upgrade/downgrade; no structural lock-in | Yes — upgrade at any time; downgrade loses features | Free tier (message history limit, limited Workflow Builder, no per-channel auto-join control) | Medium — Free tier message history limit (90 days on current Free plan) means members cannot access historical conversations after 90 days; creates a content access cliff at month three that is distinct from churn risk |
| Workspace URL | Yes — do before first invite | Technically yes, but changes break all existing member bookmarks and saved workspace links immediately and permanently | Whatever you typed during workspace creation; often a temporary placeholder or personal name | High — a workspace URL that does not match your brand (e.g. “johns-community” for a community called “Revenue Masters”) signals transience and reduces perceived professionalism at the invite-link touchpoint, which is the member’s first impression of the workspace before they join |
| Channel structure | No — channels can be added, archived, renamed | Yes — channels can be created or archived at any time; renaming a channel breaks pinned links | Only #general exists; all new members auto-join #general; no orientation path | High — without #start-here and #introductions as the two auto-join defaults, new members’ first login is #general (typically high-volume, no orientation context); activation rates are 25–40% without a structured orientation path vs. 45–65% with one |
| Permission baseline | No — all three permission changes can be applied at any time | Yes — permissions can be changed at any time; members who joined before the @channel restriction was applied will notice the change but it takes effect immediately | All members can use @channel and @here; all members auto-join all public channels; #start-here (if created) allows member posting | High — the @channel default creates broadcast interruptions for new members before they have context; this is the primary trigger for workspace muting within the first 72 hours of membership |
| Export & retention settings | No — settings can be changed at any time | Yes | Workspace Owners can export public channel data; private channel and DM export not enabled; message retention set to keep all messages forever | Low — the default export state is conservative and appropriate for most paid communities at launch; the primary risk is not having export access when needed for moderation, billing disputes, or community health audits |
Account tier decision matrix
The decision is not which tier has the most features — it is which tier removes the structural blockers that affect activation rate without paying for features you will not use at current scale. Three variables determine the correct tier: message history access, Workflow Builder automation capability, and per-channel auto-join control. For the detailed explanation of why each variable matters for paid community member activation, see the workspace setup narrative companion.
| Variable | Free | Pro ($7.25/user/mo billed annually) | Business+ ($12.50/user/mo billed annually) |
|---|---|---|---|
| Message history | 90-day limit; older messages become inaccessible to all members | Unlimited; all historical conversations accessible | Unlimited + compliance exports |
| Workflow Builder steps per workflow | 10 steps max; no external app connectors | Unlimited steps; external app connectors available | Unlimited + enhanced variable support |
| Per-channel auto-join control | Not available; workspace-wide default only | Available in Channel Settings → More | Available + admin bulk tools |
| Slack Connect (external workspace linking) | Not available | Available | Available + enhanced controls |
| Admin audit log | Not available | Not available | Available (90-day retention) |
| Correct tier for a paid community | No — the 90-day message history limit creates a content-access cliff at month three; the missing per-channel auto-join control limits the precision of the channel restriction | Yes — correct starting tier for communities under 500 members; removes the two structural activation blockers (history limit and per-channel auto-join) at the lowest monthly cost | Premature below 500 members — the additional features (audit log, enhanced exports) are valuable for moderation and compliance at scale but the per-seat cost is harder to justify when Pro already removes the activation-affecting blockers |
The per-seat cost reality. Slack Pro billing is per workspace member, not per community member. A 300-member paid community where the operator has 5 admin/moderator accounts and all 300 members join the workspace costs approximately $2,190/year at $7.25/user/mo × 305 users on the annual plan. This is a meaningful line item. At community launch with 20–50 members, Pro costs $1,740–$2,190/year for the full eventual capacity; some operators start on Free and migrate to Pro at 50–75 members, accepting the message history gap for early cohorts as the cost of the lower starting tier.
Workspace URL naming reference card
The workspace URL is set during workspace creation and appears in every Slack invite link, browser bookmark, and “Open Slack” button that members receive and save. It is technically changeable in Settings & Administration → Workspace Settings → Workspace Name & URL, but the change breaks every saved bookmark and workspace link for all existing members immediately and permanently. Members who saved a workspace link before the change will receive a 404 when they click it. Treat the workspace URL as permanent from the first invite forward.
-
Rule 1 — Match your brand domain, not your tagline
Use the same identifier as your domain name or community brand name. If your community is called “Revenue Masters” and your domain is revenuemasters.com, the workspace URL should be
revenuemasters.slack.com. Do not use a tagline (“scale-your-revenue”), a descriptor (“the-best-saas-community”), or your personal name (“johnsmith-community”). The workspace URL is an identity signal, not a conversion tool; it should create instant recognition for a member who already purchased, not persuade a prospect who has not.revenue-masters-best-community.slack.comrevenuemasters.slack.com -
Rule 2 — Lowercase, hyphens only, no special characters
Slack workspace URLs are lowercase and accept only hyphens as separators; underscores, dots, and mixed case are not supported. If your brand name contains a space or punctuation, replace it with a hyphen or remove it entirely. A URL like
revenuemastersco.slack.com(no hyphen, “co” suffix dropped) is preferable torevenue_masters.slack.com(underscore — not supported) orRevenue-Masters.slack.com(mixed case — stored as lowercase regardless).Revenue_Masters.slack.comrevenue-masters.slack.com -
Rule 3 — No version numbers, years, or qualifiers
Avoid any element that implies a version (“v2”), a year (“2024”), or a qualifier (“official”, “real”, “new”). These create an implied expiration date: a URL containing “2024” signals staleness in 2026, and “v2” implies a v1 that was superseded. A plain brand-name URL does not age.
revenuemasters2024.slack.comrevenuemasters.slack.com
How to change the URL if you must. Settings & Administration → Workspace Settings → scroll to Workspace Name & URL → click Edit next to the URL field → enter the new URL → save. Slack will warn you that the change is immediate and permanent. After saving: (1) update every invite template and email that contains the old URL; (2) post a message in #announcements explaining the URL change and providing the new workspace link; (3) accept that members with saved bookmarks or desktop app shortcuts will need to re-add the workspace manually — there is no automatic redirect.
Minimum channel structure setup sequence
Create channels in this order. The sequence matters because the default-channel permission change (Step 6 below) requires #start-here and #introductions to exist before it can be applied, and the orientation post for #start-here (Step 4) should be written before the channel is set to operator-only posting, since you cannot post in a channel once you restrict it unless you are a workspace owner or admin. For the detailed channel-architecture reference including the full table for communities under 500 members, see the workspace configuration reference card.
| Channel | Create in this order | Posting permissions | Auto-join new members? | Pinned content required before launch? | Do not create until |
|---|---|---|---|---|---|
| #start-here | First | Workspace owners and admins only (set after pinning the orientation post) | Yes — must be in the two-channel default set | Yes — orientation post (≤200 words; one sentence describing what the community is for and who it is for; one instruction; two or three channel links; one reference link) | Day 0 of launch; this is the workspace default channel and must exist before invites go out |
| #introductions | Second | All members | Yes — must be in the two-channel default set | Yes — a pinned introduction template post showing the format (name, role, what you’re working on, what you’re looking for) | Day 0 of launch; must exist before invites go out since it is the other auto-join channel |
| #announcements | Third | Workspace owners and admins only | Optional — add after Day 0 DM sequence is wired; do not add as a default auto-join channel | No pinned content required; add a brief channel description explaining what types of announcements will appear here | Day 0 of launch is fine; directing announcement traffic away from #general is valuable from the start |
| #general | Fourth | All members | No — explicitly remove from auto-join default if it exists; members should join after the onboarding sequence directs them | Optional: a brief community norms post (≤100 words) | After month two when the community has enough historical conversation to feel active when a new member opens it; a #general channel launched on day one with zero history signals emptiness |
| #[topic-1] and #[topic-2] | Fifth | All members | No — members join via goal-track routing in the Day 0 DM sequence | Optional: a seed thread or question from the operator to give new joiners a first posting entry point | After you have identified the two or three most common member goal types from the first 10–15 intake responses; topic channels created before member goal data exists tend to be misnamed relative to how members actually describe their interests |
| #best-of or #resources | Sixth (optional) | Workspace owners and admins only (operator-curated) | No — linked from #start-here orientation post as the explore-the-archive reference link | No pinned content required; the channel itself is the curated archive | After month six when the thread archive is deep enough to curate (minimum: 10 threads worth preserving); creating this channel before the archive exists signals ambition, not depth |
Permission baseline configuration cards
Two configuration changes from the workspace configuration reference card reproduced here in condensed form for the setup sequence. The full step-by-step instructions with verification procedures are in that companion reference; these cards provide the admin path and target state in compact form for operators working through the setup checklist. A third change — #start-here operator-only posting permissions — is applied as part of the channel structure sequence above (after the orientation post is pinned).
Default channels at invite: #start-here and #introductions only
Remove all channels from the default set. Add #start-here and #introductions. Save. This change only applies to future invites — it does not remove existing members from channels they have already joined. Apply this change before the first invite goes out.
Verification
Accept a test invite in an incognito window using a secondary email not currently in the workspace. After completing Slack account setup, confirm that only #start-here and #introductions appear in the sidebar. If other channels appear, check per-channel auto-join settings on each channel (Channel Settings → More, paid plans only).
@channel and @here: workspace owners and admins only
This change takes effect immediately. Existing members cannot use @channel or @here after the setting is saved. Apply this before the first invite goes out, not after the first member-generated @channel ping trains workspace muting in early joiners.
Verification
Log into a non-admin member account and attempt to type @channel in any channel. Slack should display a warning that you do not have permission to use @channel in this workspace. If the @channel completion still appears and sends successfully, the permission did not save — retry the save and verify again with the test account.
Data export and retention settings reference
The default Slack export settings are conservative and appropriate for most paid communities at launch. This table documents the default state of each setting, the recommended state for a paid community, and the admin path to change it. The primary risk with leaving these at defaults is not a compliance problem but an operational one: if a moderation dispute, billing conflict, or community health audit requires access to conversation history, export access must be pre-configured before the fact. Configuring it after a dispute has started adds friction to an already difficult situation.
| Export type | Slack default | Admin path to change | Who can export (default) | Recommended state for a paid community |
|---|---|---|---|---|
| Public channel message export | Enabled; Workspace Owners can export public channel data using the standard export tool | Workspace Settings → Permissions → Message Retention & Deletion | Workspace Owners | Leave at default; restrict to Workspace Owners only (not Admins) on paid plans where the distinction matters |
| Private channel and DM export | Disabled; requires Business+ or Enterprise Grid and explicit opt-in via Slack’s compliance exports setting | Workspace Settings → Permissions → Message Retention (Business+ only) | Workspace Owners (Business+ with compliance exports enabled) | Leave disabled unless you have a specific compliance requirement; the privacy expectation for DMs in a paid community is that they are private to the participants |
| Message retention period | Keep all messages forever (no deletion) | Workspace Settings → Permissions → Message Retention & Deletion → set retention period per channel type | Workspace Owners and Admins | Leave at default (keep all messages forever) unless a specific legal or data-minimisation requirement mandates a retention limit; for a paid community, historical conversation is an asset (members who joined later access it), not a liability |
Pre-launch verification test
Run this five-point test before sending the first invite. The test uses a real invite to a secondary email account, not just a review of the settings panel. The settings panel shows what was saved; the test reveals what actually happens when a new member joins. These are not the same. To run the test: create a secondary Slack account using a personal email not currently associated with the workspace, send an invite to that email, and accept it in an incognito or private browsing window. Then check each of the five conditions below. For the full channel-architecture audit that extends beyond the pre-launch minimum, see the Slack member onboarding checklist.
| Test | How to perform | Pass condition | Fail fix |
|---|---|---|---|
| Default channels | Accept invite in incognito window; observe sidebar immediately after join sequence completes | Exactly two channels visible: #start-here and #introductions. No other channels in sidebar. | Check Workspace Settings → Invitations → Default channels. If correctly set but other channels still appear, check each channel’s individual auto-join setting (Channel Settings → More on paid plans). Disable auto-join on any channel appearing in sidebar that is not #start-here or #introductions. |
| @channel restriction | Log into non-admin test account; attempt to type @channel in #introductions | Slack displays “You don’t have permission to use @channel” warning; message does not send. | Navigate to Workspace Settings → Permissions → Messaging → Who can use @channel and @here. Confirm “Workspace Owners & Admins” is selected and “All Members” is deselected. Save and re-test. |
| #start-here posting restriction | Log into non-admin test account; open #start-here; observe the message composer area | Message composer shows “You can’t send messages in this channel” or equivalent read-only notice. | Open #start-here as an admin. Click the channel name at top → Settings → Posting permissions. Set to Workspace Owners & Admins only. Save. |
| #start-here orientation post | Open #start-here as the test member; read the first visible item in the channel | Pinned orientation post is the first visible item; post is ≤200 words; contains one specific instruction (e.g. “go to #introductions and post an introduction”); contains 2–3 channel links; no broken links. | If the pinned post is not the first visible item, delete or archive any older messages that appear above it. If the post is over 200 words, edit it down — move reference content to a Canvas linked from the orientation post. If links are broken, update to the correct channel names (note: renaming a channel breaks pinned links to it). |
| #introductions template post | Open #introductions as the test member; read the pinned post | A pinned template post is visible showing the introduction format (name, role, what you’re working on, what you want from the community). The template should be pinned, not buried below other member posts. | If the template post is not pinned, open it as an admin, hover over the message, click the three-dot menu, and select “Pin to channel.” If no template post exists, write one as the operator account following the format above, post it, and pin it. |
Frequently asked questions
At what point in the workspace setup process should the three onboarding configuration changes be made?
The three onboarding configuration changes — restricting default channels to two, restricting @channel and @here to admins, and creating #start-here with operator-only posting and a pinned orientation post — should all be made before the first member invite is sent. The correct sequence is: (1) set account tier and workspace URL first; (2) create the minimum channel set; (3) apply the three permission changes; (4) write and pin the #start-here orientation post; (5) run the five-point pre-launch verification test; (6) send the first invite only after all five verification steps pass. The default-channel restriction only applies to future invites, not to members already in the workspace, so it must be in place before any invite goes out. The @channel restriction should be applied before any member can post, because one unrestricted broadcast ping from a test member during setup is enough to train workspace muting in early joiners before the community has enough context to make those pings meaningful.
How do you change the default channel set for new member invitations?
The default channel set is in Workspace Settings under Invitations. The exact admin path: click the workspace name in the top-left corner of Slack → Settings & Administration → Workspace Settings → find the Invitations section → click Expand or Edit next to “Default channels” → remove all currently listed channels by clicking the × next to each channel name → add #start-here and #introductions → save changes. This setting is available on all Slack plan tiers including Free. The change takes effect immediately for all future invites and does not affect existing members. If new members still appear in unexpected channels after the change is saved, check for per-channel auto-join settings — on Pro and above, individual channels can override the workspace default in Channel Settings → More → auto-join toggle. Per-channel auto-join must be disabled separately on each affected channel.
What is the admin path for restricting @channel and @here permissions?
The @channel and @here permission restriction is in Workspace Settings under the Permissions tab. The exact admin path: workspace name (top-left) → Settings & Administration → Workspace Settings → Permissions tab → Messaging section → find “Who can use @channel, @here, and @everyone” → select “Workspace Owners and Admins” → deselect “All Members” → save. After saving, verify with a non-admin account: attempt to type @channel in a channel message. Slack should display a warning that the member does not have permission to use @channel. If @channel still completes and sends successfully, navigate back to Messaging, confirm the setting shows Workspace Owners and Admins, and save again.
How do you verify that the default channel change took effect?
The most reliable verification method is a test invite accepted in an incognito or private browsing window using a secondary email address that does not have an existing Slack account in the workspace. Accept the invite, complete the Slack account creation process, and observe which channels appear in the left sidebar immediately after the new-member join sequence completes. If the change is correctly applied, only two channels should appear: #start-here and #introductions. If additional channels appear, check per-channel auto-join settings on each channel that should not be appearing (Channel Settings → More on paid Slack plans). Disable auto-join on those channels. The workspace-wide Invitations setting and per-channel auto-join are independent mechanisms — both must be configured correctly for the two-channel restriction to hold. Do not rely on the settings panel to confirm success; only a test invite confirms what actually happens when a new member joins.
What is the maximum number of channels a new member should see on their first login?
The target is exactly two: #start-here and #introductions. Communities where new members see 10+ channels on first login report 7-day activation rates of 25–40%. Communities that restrict first-login channels to two report 7-day activation rates of 45–65% at comparable price tiers and community sizes. The mechanism is not subtle: a member who opens a workspace and sees two channels with immediately legible content (an orientation message, and recent introduction posts from other members who joined before them) has a lower first-action cost than a member who opens a workspace and sees 20 channels showing as unread, without context for any of them. The two-channel target applies specifically to the auto-join default — members voluntarily join additional channels after the onboarding sequence directs them to 2–3 topic channels based on their stated goals. The sidebar grows to 5–8 channels within the first week for an activated member, but the first-login experience should be exactly two.