Skip to main content
Normally, anyone who messages a Gumloop agent in Slack needs their own Gumloop account, because the agent runs on that person’s credentials. This feature lets an organization lift that requirement for specific agents: people in a Slack workspace you have registered can message those agents with no Gumloop account at all, and their requests run on a shared organization service account instead of a personal one.
Enterprise plan required. Registering Slack workspaces and creating a service account both require the Admin or Security organization role.

​
When to use it

Company-wide helpdesk agents

An IT or HR agent that everyone in your Slack workspace should be able to ask questions, even the majority of employees who never log in to Gumloop.

Broad rollout without seats

You want Slack-first adoption across hundreds of people without provisioning a Gumloop account for each of them first.

One consistent identity

Every request should hit the same connected accounts and produce the same behavior regardless of who asked, instead of depending on each person’s own connectors.

Not for personal data

Because everyone shares one identity, this is the wrong choice for agents that read the asker’s own mailbox, calendar, or files. Leave those on personal credentials.

​
How it works

Three things must line up before a person without a Gumloop account can use an agent from Slack:
1

The organization has an active service account

A non-human Gumloop identity that Slack-originated requests execute as.
2

Their Slack workspace is registered to your organization

Access is granted per workspace, not per person.
3

The specific agent is opted in

The agent must be shared with the organization and have Allow Slack members without Gumloop accounts turned on.
If any one of these is missing, nothing changes for that person: they get the usual sign-up prompt. The feature is off by default for every agent and fails closed.
People who do have a Gumloop account are unaffected. If a Slack user’s email matches a Gumloop account, their request runs on their own account as it always has, even when the toggle is on. The service account is only used for people who have no Gumloop account.

​
Step 1: Create an organization service account

Go to Settings → Organization → General and find the Service account section, then click Create account.
Service account section in organization settings showing one service account with a synthetic email address and a General custom role
Gumloop provisions a synthetic organization member that nobody can log in to. It has: You get one active service account per organization, and it is the identity for all Slack requests from people without Gumloop accounts, across every opted-in agent.

​
Restricting what the service account can do

Because every unsigned Slack request executes as this account, it is worth treating it like any other principal you would lock down. Click the service account row to open Manage Access, where you assign Custom Roles that control the apps, tools, scopes, nodes, and AI models it may use, plus per-user usage caps. The three-dot menu on the row also lets you copy the service account ID or remove it.
Manage Access sheet for the organization service account showing its email, ID, creator, and a list of assignable Custom Roles
Give the service account a dedicated Custom Role rather than leaving it on your organization default. A tight role is the single best lever for limiting the blast radius of broad Slack access.
Removing the service account immediately stops all access for people without Gumloop accounts. Existing conversation history stays intact.

​
Step 2: Register your Slack workspace

In the same settings page, find Slack workspaces and click Add workspace.
Slack workspaces section in organization settings listing one registered workspace with its name, who added it, its Slack workspace ID, and the date added
A popup runs Slack OAuth. Pick the exact workspace you want to authorize in that popup; the list updates automatically once authorization completes. Each row records the workspace name, its Slack workspace ID (T…), who added it, and when. You can register multiple workspaces (for example an internal workspace plus a community one). Each is authorized independently, and removing one does not affect the others.
Registration is per Slack workspace, not per Slack Enterprise Grid organization. If your company runs a Grid with several workspaces, an admin must add each workspace individually. Being in the same Grid as a registered workspace is not enough.
Each section prompts you if the other half is missing: the Slack workspaces card tells you to create a service account, and the service account card tells you to add a workspace. Both must exist before any agent can be opted in.

​
Step 3: Opt in a specific agent

Open the agent and click Share. Two things are required in this dialog:
  1. Set General Access to Organization.
  2. Turn on Allow Slack members without Gumloop accounts.
Agent share dialog with General Access set to Organization and the Allow Slack members without Gumloop accounts toggle switched on
The toggle only appears when you can edit the agent, the agent belongs to your organization, and General Access is already set to Organization. If your organization setup is incomplete, the dialog shows a setup link instead of the toggle:
Why Organization and not “Anyone with link”? Public agents are not allowed to carry agent-owned credentials, so they must never inherit the organization service account. The organization-level share is what gates service account execution. If you later switch the agent’s General Access to Anyone, Slack access for people without Gumloop accounts stops working.
Opt-in is per agent. Turning it on for one agent does not affect any other agent, and it can only be changed from this control, not through the general agent settings save path.

​
Credentials: what the agent can actually touch

This is the part most people get wrong on the first try. The service account is a brand new identity with no connected apps of its own. It cannot borrow the admin’s personal connections, and it cannot borrow the Slack user’s connections either. So for tools to work in a Slack request from someone without a Gumloop account, the agent’s connectors must be set to agent-owned — an account explicitly pinned to the agent, which everyone using the agent acts as. If a connector is left user-owned, the request fails with a message like:
People without Gumloop accounts are never shown the usual “connect this app” prompt, because there is no account for them to connect it to.
1

Open the agent's Apps and pick the connector

Select the specific account you want the agent to use.
2

Set Credential ownership to Agent-owned

See Agent-Owned Credentials for the full walkthrough. Connectors in this mode show an Agent Owned label in the tool list.
Credential ownership section in a connector detail view showing the User-owned and Agent-owned options
In organizations, agent-owned credentials are restricted by default. If the Agent-owned option is greyed out for you, an admin has to enable the Agent-owned credentials feature toggle on your Custom Role first.
Agent-owned pins are tied to the space the agent lives in. Cloning the agent, using it as a template, or moving it to another team drops the agent-owned pin, and the connector reverts to user-owned. If you move or copy an opted-in agent, re-check its credential ownership.

​
Attribution, credits, and auditing

  • Runs execute as the service account. Permissions, Custom Role restrictions, and org policies are all evaluated against the service account, not the Slack person and not the admin who created it.
  • The Slack person is still recorded. Each request stores the originating Slack actor (platform, workspace ID, Slack user ID, display name) alongside the conversation, so you can see who actually asked.
  • Usage draws on organization credits, not on any individual’s balance.
  • Setup changes are audit-logged: service account creation and removal, and Slack workspace registration and removal all emit audit log events.

​
Who is eligible

Registering a workspace authorizes its full members. Gumloop deliberately excludes several categories, all of which fall back to the sign-up prompt:
Shared channels are the case to watch. Registering a workspace does not extend access to Slack Connect partners in channels you share with them. That is intentional, but it also means an opted-in agent living in a shared channel behaves differently for your own members than for the partner’s members.

​
Frequently asked questions

No. Registering a workspace grants nothing by itself. Each agent must be individually shared with your organization and individually opted in. The default for every agent, including newly created ones, is off.
No. Authorization is based on the specific Slack workspace ID, so each workspace in a Grid must be registered on its own. If you run a Grid, register every workspace whose members should have access, and verify the behavior for members whose home workspace differs from the one they are posting in.
Two separate things. The execution identity is the organization service account, a synthetic non-human Gumloop user. The integration credentials are whatever the agent owner pinned as agent-owned. Never the admin’s personal login, and never the Slack user’s own connected accounts.
Work down the list: is the toggle on for that agent; is General Access set to Organization; is their workspace registered (not just another workspace in the same Grid); are they a full member rather than a guest or Slack Connect user; and does an active service account exist. Any single missing piece produces the sign-up prompt.
That specific wording means the agent is opted in and the workspace is registered, but there is no usable active organization service account — usually because it was removed after the agent was enabled. Recreate it in Settings → Organization → General.
Nothing changes for them. Their Slack requests keep running on their own account and their own credentials. The service account path applies only to people with no matching Gumloop account.
Yes, at three levels. Turn off the agent’s toggle to revoke one agent. Remove a Slack workspace to revoke one workspace while leaving others intact. Remove the service account to revoke all unsigned Slack access across the organization at once. All three take effect for subsequent requests; existing conversation history is preserved.
Yes. Assign the service account a restrictive Custom Role through Manage Access. Since every unsigned Slack request runs as that one account, its Custom Roles are an effective org-wide ceiling on this whole surface. Restricting the agent’s tool list is the other lever.
Yes, they draw on your organization’s credits, since the service account is an organization member.
No. This feature does not change where agents can live. Agents work in public and private channels, not in direct messages. See Using Agents in Slack.
The toggle is only rendered when you have edit access to the agent, the agent is owned by your organization, and General Access is already Organization. On top of that, your organization must be on Enterprise. If setup is incomplete you see a setup link in its place instead of the toggle.

Using Agents in Slack

Adding agents to channels, Slack preferences, commands, and how credentials work for signed-up users.

Agent-Owned Credentials

Pin one account to an agent so everyone using it acts as that account. Required for this feature’s tools to work.

Custom Roles

Restrict the apps, tools, scopes, nodes, and models the service account may use.

Share Permissions

How General Access rings work, including the Organization level this feature requires.