Everyone
## What should I decide before setup?
Decide these or have them handy. Anything open can wait for your setup call.
OrganizationCompany settings, roles, and policies
TeamsShared spaces for people who work together
AgentsDo the work, with Owners who maintain them
ConnectorsThe apps agents reach, through a personal or shared account
| Area | Have ready |
| - | - |
| [Identity](#identity) | Identity provider, whether the pilot needs SSO or SCIM, and your setup admins |
| [Membership](#general) | Invite-only or domain auto-join, and whether chats and files can be shared externally |
| [Apps](#connectors) | Pilot apps, tools or scopes to restrict, and personal or shared Team accounts |
| [Models](#models) | Approved models, retention needs, and whether to use your own provider keys |
| [Guardrails](#connectors) | Actions to block and who approves access requests |
| Security and legal | Security review, questionnaires, DPA or MSA, and audit log needs |
| [Pilot](#agent) | Department lead, first task, kickoff date, and shared Slack channel members |
**Learn more**
[Gumloop Trust Center](https://trust.gumloop.com)
[AI Model Governance & Configuration](/enterprise-features/ai_model_control)
[App Rules](/enterprise-features/app-policies/app-rules)
IT admin
## What should I review in General settings?
Decide where new members land and who approves their requests.
**Recommended setup**
**Domain whitelisting:** Add every company email domain so employees join without an invitation. Finish the default Custom Role (step 05) before you announce Gumloop.
**Default Team:** Your pilot Team, once you create it in step 07.
**Approval assignees:** Your IT admin for every request type.
Open organization [**General**](https://www.gumloop.com/settings/organization/general), headed **Organization Overview**, and review the existing setup before adding members.
Review **Organization Name** and the copyable **Organization ID** used for support. For **Default Team**, choose where new members should land, or **No default team**. Revisit this after creating the pilot Team.
Check domains already listed. **Add domain** lets matching new users automatically join without an invitation. Review this now, but prepare your default role, model access, connector restrictions, and default Team before enabling new auto-join domains.
Review **Approval assignees** for **Feature access**, **Credit limits**, **Model access**, **App access**, and **Organization roles**. Decide who should receive each kind of access request.
Domain whitelisting lets matching new users join automatically. It does not enforce SSO, and removing a domain does not remove existing members.
**Done when:** you know where new members land and who approves their requests. Optional General settings, such as artifact domains and Slack service accounts, are in [Additional controls](#advanced).
**Learn more**
[Organization and Teams](/core-concepts/teams#setting-a-default-team)
[User Roles](/core-concepts/organization_user_roles)
IT admin
## Who should help with setup?
Give IT the authority to configure the pilot without making every employee an admin.
**Recommended setup**
**Admin:** Two or three IT admins, so setup never depends on one person.
**Security:** Your security owner.
**Everyone else:** Member only.
Invite only the people who need to configure the organization at this stage. Invite the wider pilot after the access policies are ready.
Open organization [**Members**](https://www.gumloop.com/settings/organization/members). In **Add Member to Organization**, enter **Email**, select the necessary **Roles**, then click **Add**.
Use **Admin** for organization setup and **Security** for security controls. Admin also covers billing and SSO, so keep that group small.
**Done when:** your setup owners have accepted their invitations and can reach the settings they need. Skip this section if the required owners already have access.
**Learn more**
[User Roles](/core-concepts/organization_user_roles)
IT admin · Security
## Which models and defaults should I approve?
Pick the approved models before anyone starts using agents.
**Recommended setup**
**Restrict model access:** On, with **Block Selected**.
**Blocked models:** Only models your company does not allow, such as open-source models or specific providers. Leave everything else available.
**File Sharing Behavior:** **Default**.
Set model policy before inviting the pilot, and review agent defaults before anyone creates the first agent.
Open organization [**Models**](https://www.gumloop.com/settings/organization/models). Under **Restrictions**, turn on **Restrict model access** and choose **Allow Only Selected** for an approved list, or **Block Selected** for specific exclusions.
Open organization [**Agents**](https://www.gumloop.com/settings/organization/agents). Review **Model** and **File Sharing Behavior**. **Default** inherits chat and agent permissions; **Organization** shares generated files across the organization.
**Done when:** the default model is allowed. Agent defaults do not change existing agents. Custom Roles cannot allow a model blocked organization-wide.
Provider keys and model proxies are optional, not prerequisites.
**Learn more**
[AI Model Governance & Configuration](/enterprise-features/ai_model_control)
[Agent Default Settings](/enterprise-features/agent_default_settings)
Security
## How should I prepare Custom Roles?
Separate the people building agents from the people using them, without piling on unnecessary roles.
**Recommended setup**
**Default role:** **Full access**, with the changes below.
**Features:** Turn off **External chat sharing** and **External artifact sharing**. Turn on everything else.
**Usage Limits:** Set **Concurrent Agent Limit** to 10, so one heavy user cannot hold up everyone else.
**Extra roles:** Only for groups that need different access.
Prepare the default role before new employees join. Organization roles grant administrative authority; Custom Roles control connector, model, feature, and usage restrictions.
Open organization [**Custom Roles**](https://www.gumloop.com/settings/organization/groups). Review the role automatically assigned to new members. Keep it if it already meets your requirements.
Click **Create Role**. Choose **No access**, **Full access**, or **Start from template**, then **Next**. Enter **Role name**, then **Confirm**.
Review **Connectors** (which apps, tools, and scopes the group can use), **Models**, **Features**, and **Usage Limits**. A **No access** role needs explicit grants before members can use it. Review **Agent modification** for the department lead creating the agent.
A stricter role does not override access allowed by another assigned role. Check the default and every additional role together. The first Custom Role becomes the default if none exists.
Review **External chat sharing**, **External artifact sharing**, and **Agent-owned credentials** in **Features** when the pilot needs restrictions on external access or shared-account use. An agent's own access and file-sharing settings still need a separate review.
**Done when:** the default is ready for new members. Assign additional roles through the role's **Users** tab or the member invitation dialog.
**Learn more**
[Custom Roles](/enterprise-features/user_groups)
Security
## How do I approve connectors?
Decide which apps the pilot can use and what agents may do in them.
**Recommended setup**
**Rules:** Start with none. Add a rule only for a specific action to block, such as emails to external domains.
**Domain Restrictions:** Require your company email domain for new connections.
**Claims:** Claim your company's workspaces where available.
You chose which apps each group can use in [Custom Roles](#roles). **Policies** add optional company-wide rules on top. Allowing an app and connecting an account are separate steps.
Use organization [**Policies**](https://www.gumloop.com/settings/organization/policies) when your company requires these controls:
| Control | Use it to |
| - | - |
| **Rules** | Block or tag particular tool calls. |
| **Domain Restrictions** | Require corporate email domains for new OAuth connections. |
| **Claims** | Claim a provider workspace for your organization. |
**Done when:** you know which apps are approved, which account each will use, and whether company-wide policies are needed.
OAuth **Domain Restrictions** govern connector accounts. They are not the same as organization **Domain Whitelisting**, which controls automatic organization membership.
**Learn more**
[App Policies](/enterprise-features/app-policies/overview)
[App Rules](/enterprise-features/app-policies/app-rules)
[Domain Restrictions](/enterprise-features/app-policies/domain-restrictions)
[App Claims](/enterprise-features/app-policies/app-claims)
[Connectors](/core-concepts/credentials)
IT admin · Champion
## How should I organize Teams?
Provide a shared home only where collaboration or shared accounts are needed.
**Recommended setup**
**Teams:** One Team for the pilot department.
**Accounts:** Personal accounts by default. A shared Team account only for shared sources, such as a team drive.
Create one pilot Team for shared work, not a Team for every entry in your org chart.
On the Home page, click **+** beside **Teams**. In **New Team**, enter **Team Name**, then **Create**.
Expand the Team and open **Connectors**. A Team Admin can find the approved service and click **Add**. Review **Team credential addition** in their Custom Roles too.
Use personal accounts when each participant should act as themselves. Use a shared Team account only when everyone should have that account's access. Limit shared accounts to the pilot's approved data.
**Done when:** the Team exists, its administrator is identified, and any shared account has the right source permissions. Review the default Team in [**General**](https://www.gumloop.com/settings/organization/general) after creating Teams, before new members join.
**Learn more**
[Organization and Teams](/core-concepts/teams)
[Connectors](/core-concepts/credentials)
IT admin
## When should I configure SSO and SCIM?
Make sure the next sign-in works for everyone, not just your current session.
**Recommended setup**
**SSO:** The identity provider your company already uses for other tools.
**SCIM:** On if you offboard people through your identity provider.
**Before activating:** Test a fresh sign-in with a non-admin account.
If you require SSO, set it up before inviting the pilot. Your IT setup group can join first.
Open organization [**Identity Provider**](https://www.gumloop.com/settings/organization/sso) settings and follow the matching provider guide in [SSO: SAML, OIDC & SCIM](/enterprise-features/sso_saml_oidc_scim).
Test with the IT owner and a pilot member, using a fresh sign-in. For Okta OIDC, **Run test** must pass before activation. Match account emails and assign every existing user who needs access to the Okta app.
Use SCIM for automated provisioning, offboarding, and role or Team mappings. Request enablement from support, and set the mappings before syncing the wider group. SCIM runs through a SAML app even if sign-in uses OIDC, and removing someone's SAML app assignment can deactivate them in Gumloop.
Activating SSO turns off Google and email sign-in for your SSO domains. Test a fresh sign-in first; staying signed in is not proof the next sign-in works.
**Done when:** an ordinary pilot member can sign in, and provisioning places them in the expected roles and Teams. Keep manual invitations and identity-provider provisioning aligned.
**Learn more**
[SSO: SAML, OIDC & SCIM](/enterprise-features/sso_saml_oidc_scim)
[OIDC with Okta](/enterprise-features/idp-guides/oidc-with-okta)
[SCIM with Okta](/enterprise-features/idp-guides/scim-with-okta)
[SCIM with Entra](/enterprise-features/idp-guides/scim-with-entra)
Champion · IT admin
## How do I launch the first agent?
Start with a task the department cares about, not a perfectly configured but unused agent.
**Recommended setup**
**Who Can Use:** **Team**.
**Owner:** The department lead.
**Task Visibility:** **Their tasks only**.
**Sensitive tools:** **Ask for writes/deletes** on anything that sends or changes data.
Choose a first task with the department lead before configuring the agent. For an HR & People pilot, the goal can be: answer a handbook question, cite the policy, and refer unanswered questions to HR, without accessing employee records.
Invite the lead from organization [**Members**](https://www.gumloop.com/settings/organization/members) with the pilot's **Custom Roles** and **Team**, so they can build the agent before the rest of the pilot joins.
Open the Team's **Agents** page and create the agent. In **Agent**, describe its job and boundaries.
```text Example instructions wrap theme={"dark"}
Answer policy questions using only the approved sources.
Cite the source. If it does not answer the question, say so and refer to HR.
Do not access employee records or change HR systems.
```
In **Connectors**, add the app that holds the approved sources, such as the drive with your handbook. Select **Use Personal Default** for each person's account or **Use Team Default** for the shared account. Adding a Team connection does not select it automatically. Deny unnecessary tools; use **Ask for writes/deletes** for enabled sensitive tools.
Set **Who Can Use** to **Team**. Add the department lead as an **Owner**. Set **Task Visibility** to **Their tasks only** for this pilot; new team agents default to **Team tasks**. Review **File Sharing**, **Create Triggers**, and **Make a copy**, then **Save**.
Start a **New Task** and try this prompt. Review the answer with the department lead before testing as an ordinary member.
```text Test prompt wrap theme={"dark"}
What does the approved employee handbook say about taking time off? Cite the policy, and tell me if the sources do not answer the question.
```
**Done when:** Users can run the agent without editing it. Owners and authorized administrators retain administrative visibility; **Their tasks only** is not a confidential channel hidden from them. Instructions do not enforce data access, so restrict the account and tools too.
**Learn more**
[Agents](/core-concepts/agents)
[Agent Access](/core-concepts/agent_access)
[Connectors](/core-concepts/credentials)
IT admin
## When should I invite employees?
Invite people once there is something useful and safe for them to use.
**Recommended setup**
**Pilot group:** A small group from one department.
**Assignment:** The pilot Team and the default Custom Role.
Invite the pilot once the first agent works and sign-in is ready.
For manual invitations, open organization [**Members**](https://www.gumloop.com/settings/organization/members). In **Add Member to Organization**, enter **Email**, select **Custom Roles** and **Teams**, and click **Add**. Every member has the baseline Member role; add other organization roles only when needed.
Wait for acceptance. For someone already in the organization, right-click the Team and choose **Invite to Team**. If SCIM manages membership, verify the identity-provider assignment and sync instead.
**Done when:** the member has the expected Team, Custom Roles, and model access. Do not use an Admin account as your only test.
If you want domain-based automatic joining, enable it only after these defaults are ready and confirm the landing experience.
**Learn more**
[User Roles](/core-concepts/organization_user_roles)
[Organization and Teams](/core-concepts/teams#adding-team-members)
Champion · IT admin
## How do I check that setup is ready?
Prove usefulness and access boundaries before expanding the audience.
**Recommended setup**
**Testing:** Use a non-admin account.
**Expanding:** One team at a time, after the department lead signs off.
Test as an ordinary pilot member before inviting a wider audience.
| Test | Expected result |
| - | - |
| Join and sign in | The intended organization, Team, and roles are applied. |
| Run the agent | The approved model and intended connector account work. |
| Ask a supported question | The answer cites an approved source. |
| Ask for unavailable data or an unnecessary action | No unauthorized data or tool is available. |
| Check User access | No editing or browsing another User's tasks. |
Review organization [**Insights**](https://www.gumloop.com/settings/organization/insights) for adoption and spend, and [**Audit Logging**](https://www.gumloop.com/settings/organization/audit-logging) for administrative changes. Give reporting responsibilities to the appropriate [User Roles](/core-concepts/organization_user_roles), not blanket Admin access.
**Done when:** the department lead accepts the results and owns ongoing corrections. Share the agent link, supported tasks, and contact person, then expand membership in stages.
**Learn more**
[Organization Insights](/enterprise-features/organization_insights)
[Audit Logging](/enterprise-features/audit_logging)
[User Roles](/core-concepts/organization_user_roles)
## Frequently asked questions
Short answers to what new admins ask most.
Think of five separate questions: who manages the organization, where shared work lives, what a person may use, who owns the agent, and whose external account it uses.
| Question | Control | Pilot example |
| - | - | - |
| Who manages company settings? | Organization role | IT has Admin; an employee has Member. |
| Where do people collaborate? | Team | HR & People has a shared space. |
| Which tools, models, and features may a person use? | Custom Role | The pilot gets approved apps and models. |
| Who maintains or runs this agent? | Agent Access | The lead is Owner; participants are Users. |
| Whose data can a tool reach? | Connector account | Each participant's account, or an approved shared Team account. |
No. A Team is a shared space; a Custom Role is an organization-level access policy. Create a Team when people need shared work. Create another Custom Role only when their policy needs differ. A department does not automatically need a one-to-one pair. See [Organization and Teams](/core-concepts/teams) and [Custom Roles](/enterprise-features/user_groups).
Access allowed by another assigned role remains available. Review the default and all additional roles together, then change the role that grants unwanted access. More roles do not necessarily mean tighter control.
No. Team membership gives User access to team agents. Maintaining an agent requires Owner access, and creating or modifying agents also depends on the person's Custom Roles. Team Admin and agent Owner are different responsibilities. See [Agent Access](/core-concepts/agent_access).
No. **Use Personal Default** uses the running person's account. **Use Team Default** uses the shared Team account. Configure that choice explicitly on the agent. An app allowlist is permission, not authentication. See [Connectors](/core-concepts/credentials).
Agent Owners can see every task on the agent. Users see what **Task Visibility** allows. Authorized administrators keep administrative visibility, so **Their tasks only** is not a private channel. See [Agent Access](/core-concepts/agent_access).
Every model Gumloop serves runs under zero data retention except Anthropic's Claude Fable family, which keeps prompts and outputs for 30 days to check for misuse and does not train on them. Turn off **Allow non-zero data retention models** in **Models** to exclude them. See [AI Model Governance & Configuration](/enterprise-features/ai_model_control).
Remove them from the three-dot menu on [**Members**](https://www.gumloop.com/settings/organization/members), or let SCIM deprovision them. Their active triggers turn off. Nothing else is deleted, so a remaining member re-creates any trigger that should keep running. See [User Roles](/core-concepts/organization_user_roles#removing-a-member).
With OIDC sign-in, Gumloop matches an existing account by email on first sign-in. Check that emails in your identity provider match the accounts people already use. See [SSO: SAML, OIDC & SCIM](/enterprise-features/sso_saml_oidc_scim).
No. Domain whitelisting admits matching new users to the organization. SSO controls sign-in through an identity provider. OAuth Domain Restrictions govern new connector authentications. Review each independently; configuring one does not replace the others.
## What else can I configure at enterprise level?
Add controls for a real requirement rather than treating every enterprise feature as mandatory.
Configure these when a company requirement or use case needs them. They are not all prerequisites, but a mandatory network or security requirement belongs before the affected pilot.
Review [**Usage & Limits**](https://www.gumloop.com/settings/organization/limits) with your budget owner, alongside Custom Role usage caps and approval assignees. See [Credits](/core-concepts/credits) for how usage is counted. Use [Organization Skills](/core-concepts/organization_skills) for shared agent guidance.
Review **Custom artifact domain** for branded file hosting, and **Slack workspaces** plus **Service account** for Slack-based agent access. Use **Google Workspace directory** or **Microsoft directory** when you need [Brain](/core-concepts/brain) to honor source-group permissions. Directory access is separate from SSO.
Use organization [**API Keys & Proxies**](https://www.gumloop.com/settings/organization/api-keys) for provider credentials and model routing. [**OAuth Configuration**](https://www.gumloop.com/settings/organization/oauth-configuration) is separate and applies to supported connector authentication. See [AI Model Governance & Configuration](/enterprise-features/ai_model_control).
Use [Hosted MCPs](/enterprise-features/hosted_mcps) for custom servers hosted by Gumloop, [Proxied MCPs](/enterprise-features/proxied_mcps) for existing servers, and [Managed Tunnels](/enterprise-features/managed_tunnels) for servers in private networks. Use [Static Egress IPs](/enterprise-features/static_egress_ips) when your network requires outbound IP allowlists.
Use [Organization Insights](/enterprise-features/organization_insights) for adoption, [Audit Logging](/enterprise-features/audit_logging) for administrative changes, [Usage Data Export](/enterprise-features/organization_data_export) for exports or data drains, and [Outbound Webhooks](/enterprise-features/organization_webhooks) for supported organization events.
Validate the agent first, then add the required communication channel. Review [Using Agents in Slack](/core-concepts/agents_slack), [Using Agents in Microsoft Teams](/core-concepts/agents_teams), and [Organization Service Accounts for Slack Agents](/enterprise-features/slack_agent_access). A Gumloop Team is not a Microsoft Teams channel.