Workspace Setup
Paid community Slack workspace setup: the decisions operators get wrong before the first member joins
Most paid Slack community operators create the workspace the same day they decide to launch: they open Slack, name the workspace, invite a handful of beta members, and start creating channels as topics come up. The decisions that are hard to undo — account tier, workspace URL, initial channel structure, member permissions, and data-export settings — are made by default rather than by choice. Six months later, the community is running on the wrong Slack plan, the workspace URL is a typo they live with, the channel list has 40 entries that no new member can navigate, and the export settings have been logging every private message since launch in a way that members would object to if they knew. This guide covers the five decisions that need to be made before the first real member invite goes out, in the order they need to be made, and the consequences of getting each one wrong after members are already present.
Why workspace setup decisions are hard to undo
Slack workspace setup decisions fall into two categories: the ones that can be changed any time without disruption, and the ones that, once members are present, produce real consequences when changed. Knowing which category a decision belongs to determines whether it needs to happen before the first invite or whether it can wait.
The decisions that can be changed any time without disruption include most of the configuration changes covered in the paid community Slack onboarding reference card: default channel settings for new invites, @channel and @here permissions, #start-here posting permissions. These are admin panel settings that take effect immediately and invisibly to members who are already in the workspace. A member who joined before you made the change does not experience a difference in their existing channels; the change only affects the experience of members who join after the setting was updated.
The five decisions that are hard or impossible to undo cleanly after members are present are in a different category:
- Account tier (Free vs. Pro vs. Business+) — determines message history retention, guest account limits, and analytics availability. Changing tiers after launch is possible but affects billing immediately and, in the case of downgrading from Pro to Free, immediately truncates message history to the 90-day window.
- Workspace URL and naming — changing the URL after members have joined forces every member to find the workspace through a new URL, breaking bookmarks, password-manager entries, and any external links that reference workspace-specific content.
- Initial channel structure — adding channels is easy and carries no social cost. Removing or archiving channels after members have joined creates friction: members who used the channel lose their history, and removing a channel that members posted in sends a social signal that the operator has decided the topic is no longer worth supporting.
- Member vs. guest permissions baseline — the permissions baseline for members (what they can post, where, and with what notification reach) is easier to restrict than to relax. Removing a permission that members have been using for months generates visible pushback. Starting restrictive and loosening permissions as trust is established is the lower-friction direction.
- Message export and data-retention settings — the default export setting allows workspace owners to export all message history including DMs. Changing this setting after members have joined does not retroactively remove messages that have already been logged; it only changes what is exportable going forward.
These five decisions need to happen in the order listed, because each one constrains the decisions that follow.
Decision one: account tier (Free vs. Pro vs. Business+)
The three plan tiers that matter for a paid community are Free, Pro ($7.25/user/month billed annually), and Business+ ($12.50/user/month). Enterprise Grid is a separate category that applies only to communities with 250+ members and enterprise procurement requirements — it is not a realistic starting point for a new paid community and is not covered here.
The key variables that determine which tier is correct for a new paid community:
| Feature | Free | Pro | Business+ |
|---|---|---|---|
| Message history limit | 90 days | Unlimited | Unlimited |
| Guest accounts | 5 total (any type) | 5 multi-channel guests per paid member; single-channel guests unlimited | Same as Pro |
| Workspace analytics | None | None | Basic member activity analytics |
| Slack Connect (shared channels) | Not available | Up to 2 external workspaces | Up to 250 external workspaces |
| Huddles (audio/video) | 1:1 only | Group huddles | Group huddles |
For most new paid communities with under 500 members, Pro is the correct starting tier. The 90-day message history limit on Free is the decisive constraint: a paid community member who joins in month 4 should be able to read threads from month 1. A community where early conversations disappear after 90 days is a community where institutional knowledge erodes systematically. Members notice this — they ask questions that were answered three months ago, because the answer is no longer visible. The operator notices it because they are answering the same questions repeatedly.
The specific scenario where Free makes sense is a pre-launch test workspace: a private workspace with fewer than 10 manually invited beta members running for less than 90 days before the real workspace launches. Beta members should be told explicitly that this workspace will be archived and replaced with the real community workspace before the public launch. The beta workspace serves as a safe environment to test channel structure and default settings without making irreversible decisions under the pressure of a live member base.
Business+ is worth the upgrade for communities where the operator needs workspace analytics to track member activity — which members posted in the last 30 days, which channels are active, which members have been silent for 60+ days. The Business+ analytics panel does not provide the activation funnel metrics that a dedicated onboarding tool produces, but it provides channel-level activity data that Free and Pro do not. For communities using Slack Connect as the primary access mechanism for enterprise members, Business+ is required to connect with more than 2 external workspaces.
Decision two: workspace URL and naming
When you create a Slack workspace, you choose a workspace name (displayed in the app header) and a workspace URL (the subdomain at yourworkspace.slack.com). The workspace name can be changed later without disruption. The URL is a different matter.
Changing the workspace URL after members have joined breaks three things simultaneously: bookmarks (members who have yourcommunity.slack.com saved in their browser open a page that no longer exists), password-manager entries (members using a password manager to log in will try the old URL and fail), and any external links that reference workspace-specific content (a thread shared on X, a help article linking to a specific channel URL, an onboarding email that tells members to visit yourcommunity.slack.com). Slack provides no forwarding from the old URL to the new one.
The URL is set at workspace creation and should be chosen with the expectation that it will be the workspace URL for the life of the community. The correct naming convention:
- Match your domain or your community platform handle. If your community lives at
community.yourbrand.com, the Slack workspace URL should beyourbrandoryourbrand-community, not a tagline or a temporary name. - Lowercase only, no spaces. Slack enforces alphanumeric characters and hyphens; spaces are not permitted in the URL slug.
- Avoid taglines that may become awkward as the community evolves. “founders-and-builders” is specific enough to create a naming problem if the community expands beyond founders. “yourcommunity-pro” or simply “yourcommunityname” is stable across audience evolution.
The most common mistake: operators name the workspace after the community’s current focus or a temporary marketing tagline, then rebrand the community 18 months later. The rebrand can update the workspace name (the visible display name) but not the URL that members have in their bookmarks. The workspace then runs indefinitely on a URL that no longer matches the brand.
Decision three: minimum channel structure before the first invite
Channels should be created in the order they will appear in the sidebar for a new member, because Slack displays channels in the order they were created within each category (starred, then joined, then browsable alphabetically). Creating channels in the wrong order produces a sidebar that does not match the priority you want new members to experience.
The minimum channel structure for a paid community under 500 members, in the order they should be created:
- #start-here — created first so it appears first. Operator-post-only, read-only for members. Contains one pinned orientation post of under 200 words with one instruction (“introduce yourself in #introductions using this template”). This channel is the only channel new members are auto-joined to along with #introductions. All other channels are joined voluntarily.
- #introductions — created second. Members can post; operators encourage it via the Day 0 DM. This is the highest-conversion first-action channel: reading how other members introduced themselves provides social proof and lowers the posting barrier.
- #announcements — operator-post-only; members can react and thread-reply but cannot create new top-level posts. This channel carries genuine announcements: new features, events, pricing changes. Not every operator uses this channel; it is worth creating early because the permission configuration is harder to add retroactively to an existing channel that members have been posting in.
- #general or community-wide discussion channel — this channel should not be on the auto-join list. New members who have been in the workspace for at least three days and have introduced themselves are directed here via the Day 3 nudge in the paid community onboarding sequence. A new member auto-joined to a busy #general channel on day one is likely to be overwhelmed.
- Two or three topic-specific channels — relevant to the community’s core use case. For a community focused on paid-community operators, these might be #tools-and-stack, #pricing-and-retention, #member-stories. Create only the channels where you can name three recent conversations that a new member would find useful. An empty or low-activity channel creates navigation surface area without providing orientation value.
The mistake most operators make is creating all channels they can imagine needing at launch, regardless of whether enough members exist to make them active. A community with 50 members and 30 channels has the channel density of a 5,000-member community. New members who open a low-activity channel and find two posts from three months ago form a low prior about the community’s vitality — a prior that carries over to their overall assessment of whether the membership is worth continuing. The Slack member onboarding checklist covers the full per-channel audit for communities that have already launched with too many channels and need to assess which ones to consolidate or archive.
Decision four: member permissions baseline and data-retention settings
Two permission categories need to be configured before the first member invite, not after: broadcast notification permissions and message export settings.
Broadcast notification permissions (@channel and @here) should be restricted to workspace owners and admins before the first invite. In Workspace Settings → Permissions → Messaging, set “Who can use @channel, @here and @everyone” to “Workspace owners and admins only.” The reason this needs to happen before the first invite is not that members will immediately abuse the permission — most will not — but that a single member sending an @channel ping in a busy channel will generate a wave of notifications for every other member who has joined that channel. A new member who receives an unexpected @channel ping in a channel where they have no context for the message is a member who mutes the channel. Muted channels are invisible channels. Once a member has configured their notifications around a noisy workspace, removing the @channel permission does not undo the notification preferences they have already set. Starting with the restrictive permission and granting exceptions (to co-moderators, community managers) as trust is established is the lower-friction direction.
Message export and data-retention settings are the category that operators most frequently overlook and most frequently wish they had configured before members joined. By default in a Slack Pro workspace, workspace owners can export all public channel message history. In Business+ and Enterprise Grid, workspace owners can also export private channel content and DMs with the appropriate admin configuration. The default is not disclosed prominently to members in the standard Slack interface.
For a paid community where members discuss business strategy, personal career situations, salary negotiations, or financial results, the standard export setting means the community operator has access to a full archive of those conversations. Members who are aware of this may modify their behaviour accordingly. Members who are not aware of it are operating under a privacy assumption that does not match the technical reality.
The setting to review before the first invite: Workspace Settings → Administration → Workspace Settings → scroll to “Import and Export Data.” Review what can be exported, by whom, and consider whether the default matches the privacy expectation you want to create for members. If you plan to restrict export to public channel history only (the most common choice for community workspaces), configure this before member DMs and private channels accumulate history you have not disclosed can be accessed.
The three immediate configuration changes (before the first real invite)
After the five structural decisions above are made, three workspace configuration changes need to be in place before the first real member invite — not the beta test invite, the first invite to a paying or waitlisted member. These changes are covered in detail (with admin-panel step-by-step instructions and verification steps) in the paid community Slack onboarding reference card. The summary:
- Default channels at invite: two only. Workspace Settings → Invitations → Default channels. Set to #start-here and #introductions only. Remove all other channels.
- @channel and @here: operators only. Workspace Settings → Permissions → Messaging. Restrict to workspace owners and admins.
- #start-here: operator-only posting, pinned message under 200 words, one instruction. Create or configure the channel with member posting disabled. Write one orientation post under 200 words with one specific action. Pin it as the channel’s first pinned message.
These three changes can be made any time without disruption to existing members. They are listed here as part of the pre-launch checklist because making them before the first invite means every member’s first experience of the workspace reflects a correctly configured environment, rather than the post-hoc-fixed environment that results from making these changes after the first cohort of members has already had a different first-visit experience.
The pre-launch verification test
Before sending the first real member invite, run a five-point verification test using a second Slack account (a personal account, or a Slack account registered to a secondary email address) that is not a workspace owner. This test should reproduce the exact experience a new member will have when they accept the invitation.
- Send a test invite to the second account and accept it. Open the workspace as the new member account. Verify that only #start-here and #introductions appear in the channel sidebar. If any other channels appear, the default channel setting in Workspace Settings → Invitations did not save correctly or has channels that were individually set to auto-join new members in their individual channel settings.
- Verify the pinned post in #start-here is visible and under 200 words. Open #start-here as the test account. Confirm the pinned message appears at the top, is readable without scrolling past multiple prior posts, and gives exactly one clear instruction. If the pinned message requires scrolling to read in full, shorten it.
- Verify @channel fails for a non-admin account. In any channel, as the test account, type @channel in the message composer. Verify that Slack shows a prompt indicating permission is restricted and the message is not sent. If @channel sends successfully, the permission change in Workspace Settings → Permissions did not take effect.
- Verify the workspace plan tier. In the test account, go to the workspace name dropdown → Settings & Administration → Billing. Confirm the current plan is Pro or above (or Free, if this is the intentional pre-launch beta workspace). If the plan shows as Free and the intention was Pro, complete the upgrade before sending the first real invite.
- Verify the workspace URL matches the domain and brand name you intend to use permanently. Confirm the URL (visible in the browser address bar as
yourworkspace.slack.com) is the URL you want members to have in their bookmarks for the life of the community. If it does not match, change it before the first real member invite is sent.
Running this test takes approximately 15 minutes. It is the most efficient use of 15 minutes available to a new paid community operator, because it surfaces every workspace configuration gap before a real member experiences it. The alternative — discovering that the default channel setting did not take effect after 50 members have joined and had the full-sidebar first experience — means those 50 members’ week-one activation rates reflect a workspace that was not correctly configured when they arrived. For the activation-rate impact of each of these configuration gaps, see the paid community member churn by tenure guide.
Frequently asked questions
Should a paid community workspace be separate from an existing business workspace?
Yes, always. Paid community members cannot be members of an internal business workspace without also seeing business channels, which creates a confidentiality problem. Slack’s guest account feature can isolate members to specific channels in a shared workspace, but guest account limits make this unworkable at any meaningful community size (5 total guests on Free; 5 multi-channel guests per paid member on Pro). The notification and permission settings appropriate for a community are different from those appropriate for an internal team. Billing is simpler in a dedicated workspace: every member is a community member and seat count maps cleanly to your community platform’s subscriber count. The only scenario where a shared workspace is workable is a very small pre-launch test environment with fewer than 10 manually invited beta members. Move to a dedicated workspace before the first public-facing invite goes out.
What is the difference between a Slack workspace and a Slack Connect channel for a paid community?
A Slack workspace is a self-contained environment where all members share the same channel sidebar, notification settings, and admin panel. It is what most paid communities use. A Slack Connect channel is a shared channel that bridges two separate Slack workspaces — it allows a member who uses Slack in their own company’s workspace to access a specific channel from your community workspace without leaving their own workspace. Slack Connect is useful for B2B communities where members want community access inside their existing work Slack rather than creating a separate login. The tradeoff: you lose control over the member’s notification settings and channel sidebar experience. For most paid communities, a dedicated workspace with standard member invitations produces a more controlled first-visit experience. Slack Connect is worth considering only when your ICP is enterprise buyers who will not accept another workspace login.
Can the workspace URL be changed after members have joined?
Technically yes — Slack allows workspace owners to change the URL in Workspace Settings. But changing the URL after members have joined breaks bookmarks, password-manager entries, and any external links that reference workspace-specific content. Slack provides no forwarding from the old URL to the new one. Members who cannot find the workspace on the next login attempt are members who do not return. The right time to choose the workspace URL is before the first member invite. Choose a name that matches your domain, your community brand, or your community platform handle, and expect to live with it for the life of the community.
What account tier is required to use Slack Connect for connecting with external member workspaces?
Slack Connect shared channels require a Pro plan or above. Free plan workspaces cannot use Slack Connect. On Pro, you can connect with up to 2 external workspaces. Business+ allows up to 250 external workspace connections. Each member’s company workspace also needs to be on a paid Slack plan for the Connect invitation to be accepted — Slack Free workspaces cannot accept Slack Connect invitations. In practice, this means Slack Connect as a community access mechanism works only for B2B communities whose members are using paid Slack at their company.
How do guest account limits affect a paid community that wants to offer a free-trial or limited-access tier?
On Pro, you can have 5 multi-channel guests per paid member (single-channel guests are unlimited). Free allows only 5 guest accounts total. For a trial or limited-access tier, the practical approach is single-channel guests: grant access to a #free-tier or #sample-content channel only. Full membership requires a standard workspace member account. The operational overhead of managing guest-to-member conversions (removing the guest account, re-inviting as a full member) is manageable at under 50 conversions per month. Above that volume, the friction is significant enough to consider whether the free-trial tier should use a separate community platform rather than a Slack guest account.