Slack workspaces under different email addresses

Two Slack workspaces, two different email addresses, one Mac. The workspace joined with the work address appears the moment the app opens. The one joined with a personal address, or with an address at a client's domain, is nowhere in the switcher, and the sign-in screen keeps offering to send a code to the wrong inbox. Nothing is broken. Slack organizes accounts around the workspace rather than around the person, and the address used to join is the key that decides what shows up.

The practical question is not whether this is possible. It is. The question is which parts of the setup stay annoying afterwards, and which of those parts are worth fixing.

A Slack account belongs to a workspace, not to a person

Every workspace membership is a separate account. It has its own display name, its own profile photo, its own notification schedule, its own status, and its own way of proving identity, whether that is a password, a magic link, or single sign on through a company identity provider. The email address is what identifies that membership inside that one workspace.

Two consequences follow, and both explain most of the confusion around multiple addresses.

The first is that one address can hold memberships in many workspaces at once. When that happens, Slack groups them together and offers all of them after a single confirmation. This is the pleasant case, and it is why some people never notice that accounts are per workspace.

The second is that two addresses produce two separate groups that Slack never joins. A membership created with a personal address and a membership created with a work address have no link between them, even when the same human sits behind both. Renaming a profile, matching the photos, or using the same password changes nothing. There is no merge operation, and there is no account page that lists every workspace a person has ever joined regardless of address.

An address is also unique within a workspace. The same address cannot hold two accounts on the same workspace, which is why people who want a second identity in one workspace end up creating a second address rather than a second account.

Why the second workspace does not appear at sign in

The default sign-in flow asks for one email address, sends a confirmation to that inbox, and then lists workspaces. The list only contains workspaces attached to the address that was typed. A workspace joined under a different address is not missing or deleted. It was never in scope for that lookup.

The way out is to sign in by workspace URL instead of by address. Every workspace has a URL in the form of a name followed by the Slack domain, and the desktop app and the web client both accept it directly. After the URL is entered, Slack asks for the address that belongs to that workspace, which is the moment the second address gets used.

Finding the URL again when it has been forgotten

The URL appears in the workspace name menu at the top of the sidebar for anyone already signed in, and it is in the original invitation email. It also appears in the address bar of any Slack link that has ever been shared, including permalinks pasted into other tools. Searching an inbox for the word Slack usually recovers it faster than trying the lookup flow with each address in turn.

Adding every workspace to the desktop app

The desktop app holds many workspaces signed in at the same time, and the addresses behind them do not need to match. The workspace rail runs down the left edge, and the button at its bottom adds another one. From there, either the URL route or the address route works, and after the sign-in completes the new workspace becomes another icon in the rail.

There is no requirement to sign out of anything first. Notification preferences, sidebar theme, custom status, and Do Not Disturb hours are stored per workspace, so a client workspace can stay silent in the evening while a main workspace stays live.

Single sign on is the one place where different addresses bite harder than expected. A workspace configured for single sign on hands the sign-in to an identity provider, and that handshake happens in the default browser. If the browser is currently signed in as a different person at that provider, the handshake completes as that person, and Slack reports that the account has no access to the workspace. The address typed into Slack is not the address that decided the outcome. The browser session was.

Where the split addresses actually cost time

The sign-in problem is solved once. The following ones repeat.

Invitations arrive in the wrong inbox. An invitation is bound to the address it was sent to. Forwarding it to another address and accepting from there creates a membership for the original address, which is the one that must be used at every future sign in.

Links open in the wrong place. A permalink to a message in the client workspace, clicked from an email or a calendar entry, opens in the browser rather than in the app unless the app is set to handle Slack links. In the browser it resolves against whatever session that browser profile is holding.

Changing an address does not merge anything. The address on a membership can be changed in that workspace's account settings, and doing so moves that one membership under the new address. It does not pull other memberships along, and it does not combine two existing accounts into one.

History limits are per workspace, not per person. On the free plan a workspace keeps the most recent 90 days of message history. A person in five workspaces sits under five separate limits with five separate billing situations, which matters when searching for something that happened in the spring.

Consolidating on one address, and why it stalls

The tidy solution sounds obvious: move every membership onto one address and let Slack group them. It works in some cases and fails in others, and knowing which case applies saves an afternoon.

It works when every workspace allows the address. A workspace can restrict membership to one or more email domains, which is standard for company workspaces. An address at a personal domain cannot be moved into a workspace that only accepts the company domain, no matter how the change is attempted.

It also runs into single sign on. When a workspace authenticates through a company identity provider, the address on the Slack account is tied to the identity in that provider rather than chosen freely in Slack settings. Changing it is an administrator action, not a personal one.

Where consolidation is possible, aliases are worth considering before creating a new mailbox. Gmail treats an address with a plus sign and a suffix as the same account, so a single inbox can receive mail addressed several ways. Slack treats those as distinct addresses, which allows one inbox to hold several memberships that Slack still sees as separate. This solves inbox routing rather than the switcher problem, so it helps with invitations and password resets but does not reduce the number of sign-ins.

The realistic goal is not one address for everything. It is knowing which address belongs to which workspace and recording it somewhere retrievable, because that single fact is what every future sign-in, invitation, and recovery flow depends on.

Notifications when several workspaces are live

Notification settings live inside each workspace, which is more useful than it first appears. Keyword alerts, channel-level overrides, mobile push timing, and Do Not Disturb hours are all set per workspace, so a client workspace can be configured to notify only on direct messages while a main workspace stays fully live.

The part that does not separate is the badge. The desktop app shows one dock icon, and unread state from every workspace collapses into it. A red dot means something arrived somewhere. Finding out where means bringing the app forward and reading the rail, which is the same interruption whether the message was urgent or was a channel that should have been muted months ago.

Two habits reduce that. The first is to mute aggressively in the workspaces that are not the main one, so a badge carries more information than it does now. The second is to set different Do Not Disturb hours per workspace rather than one global schedule, which is often left at the default because it is not where new users look.

Browser, desktop app, or one window per workspace

Three shapes are common on a Mac, and they differ less in what they can hold than in how fast a specific workspace can be reached.

	Browser tabs	Desktop app	One window per workspace
Different addresses at once	Yes, sessions are held per browser profile	Yes, signed in independently	Yes
Separate window per workspace	Only by dragging tabs out	No, one window with a rail	Yes, by design
Reachable with Command Tab	Lands on the browser	Lands on Slack, not on a workspace	Lands on the workspace
Unread state visible without switching	Tab titles only	Rail badges	Dock or switcher per window
Survives a browser sign out	No	Yes	Depends on the tool

The desktop app wins on holding sessions and loses on retrieval. Every workspace lives behind the same application icon, so the operating system has one Slack to offer and the rail is the only place where the distinction exists. When three or more workspaces are active, the rail becomes the same problem tab bars have: a row of small targets that all look alike, scanned several dozen times a day.

When the browser is where work happens

Plenty of people never install the desktop app, either because a client's security policy forbids it or because everything else already runs in a browser. In that case the question becomes which browser boundary holds the sessions.

A browser profile is a separate directory with its own cookies, history, and extensions, and it isolates cleanly. Two profiles can hold two Slack sessions under two addresses with no interference. Firefox containers do the same at the tab level through an extension Mozilla publishes, which allows two sessions inside one window. Both approaches solve isolation and leave retrieval untouched, because every profile and every container still lives inside one browser icon.

The third option is a browser built around the idea that each web app gets its own window and its own session, sometimes called an app aggregation browser. Slack sits beside Gmail, Notion, and anything else in a fixed layout, and each account keeps a persistent session rather than a tab that can be closed by accident. The Workspaces page describes how a set of apps is grouped and switched as a unit, and the supported apps list covers which services are set up to run this way. For readers comparing this category against other multi-account tools, the Wavebox comparison lays out where the approaches differ on price and platform.

What to change first

Sign in to every workspace by URL rather than by address, so the lookup flow stops deciding what is visible. Then pick one boundary for the sessions and stay on it, whether that is browser profiles, containers, or a browser that gives each account its own window such as SpaceDeck. The mistake that costs the most time is running two of those boundaries at once and losing track of which one holds which address.