Orgs, Roles, and Environments: Enterprise Administration Guide

This document describes how Thunk.AI organizes access for enterprise customers: how organizations are structured, who administers them, and how resource environments control what AI models and business application connections are available to users.

An organization (org) is the top-level tenant unit in Thunk.AI. Every user belongs to exactly one org. The org is the administrative boundary for:

Orgs are created and managed by Thunk.AI platform administrators — enterprise customers cannot self-provision orgs directly.

The platform admin is a Thunk.AI operator-level role. It is distinct from any org-level role.

Who is a platform admin: This role is held by Thunk.AI staff and is assigned by Thunk.AI — it is not something an org or its members can request or grant.

What a platform admin can do:

Platform admins cannot read or control the content inside orgs (thunks, workflows, user data) unless they are also explicitly added as org members.

Within an org, there are two administrative roles: Owner and Admin. Both have full administrative authority over the org and its environments.

The org owner is the user who was designated as owner when the platform admin created the org (typically the primary enterprise contact). There is one owner per org.

What the org owner can do:

Org admins are appointed by the owner. There can be multiple org admins.

What org admins can do:

Participant is the standard membership role for employees in the org. Participants can use the resources (API keys, environments) that have been explicitly provisioned to them — they do not automatically gain access to everything in the org.

A resource environment is a named configuration context owned by an org. It bundles together the AI models and business application connections that users and automated workflows can draw on when running thunks.

Each environment has an isolated credential that scopes its AI model and MCP server access. One environment cannot use or see the resources of another.

Setting up AI models for an org generally follows this order:

If a model requires an OAuth client-credentials connection, create it once and reuse it — models that share the same underlying client credentials (for example, every model in a given environment) can all reference the same connection rather than each creating its own. An org admin creates a credential under their own Personal environment's Connections settings: give it a name, choose Client Credentials (Machine-to-Machine) as the grant type — not Authorization Code, which is for a different, user-driven flow — and enter the token endpoint, client ID, and client secret. Once saved, the connection is assigned an ID you can reference from any model definition.

Use the Diagnostics button on the credential to confirm it can obtain a token before relying on it in a model definition. Some warnings shown there can be safely ignored as long as the token itself is retrieved successfully.

A model definition can also create its own OAuth connection inline if you'd rather not manage it separately, but it won't be reusable by other models unless you reference that same connection's ID from them.

Creating an environment starts with a name, a description, and — optionally — its deployment phases. After it's created, open the environment to change the phases or to set its members:

In org settings, open the Model Definitions tab and select New Model Definition. A model definition specifies:

Once created, a model definition is reusable — the same definition can be assigned to multiple environments rather than being configured separately in each one.

Select a model definition in the Model Definitions tab to see its settings, such as its model ID, provider, provider model, API base and API version. A model that uses a credential also shows the OAuth connection ID and the credential's Client ID. You can see the client ID only for a credential you created; otherwise it reads Not visible to you. An environment's LLMs section lists each of its models the same way, including the API version and OAuth connection ID.

To create a model that differs from an existing one in only a few settings — the same model for another environment with its own credential, or another deployment on the same endpoint — select Use as Template on the existing model's card. The new-model form opens with the model's settings copied, including the credential; enter a new prefix and change what differs. If you pick a different base model, the copied prices are cleared, since they belonged to the original model. After you create it, the new model is tested right away and the result is shown before you close the form.

From an environment's detail view, select Assign Model Definition and choose from the org's catalog. Type in the Filter box to narrow the list by name, alias, or provider. The model becomes available to anyone with access to that environment. Removing a model from an environment (via its Unassign control) does not delete the underlying model definition — it remains in the catalog and can be re-assigned or assigned to other environments.

A model definition must be unassigned from every environment it's assigned to before it can be deleted from the Model Definitions tab.

There are two tests, and they answer different questions.

Test model — on each card in the Model Definitions tab, org owners and admins see a Test model icon button. It sends a short request to that exact model definition twice, once normally and once streamed, whether or not it has been assigned to an environment yet, so you can confirm a new or edited definition works before anyone depends on it. The result shows how long the model took and what the call cost. If the call succeeds but costs $0, the result warns you: usage of that model is not being priced, so check the definition's base model and cost settings. If the model answers but the streamed request fails, the result warns you that workflows with Use streaming LLM API turned on will fail with this model; workflows without it are unaffected. If the call fails, the result says whether the credential could not get a token or the model call itself failed, and shows the error returned.

After you create a model definition, or change where it sends requests (provider, model, API base, Vertex project or location, or credential), it's tested the same way right away and the result is shown before you close the form. For a Gemini model on Vertex AI whose API base is a gateway address rather than the full model path, the form warns that streamed requests may fail there. On a new model it offers Use full model path; test the model after switching, because some gateways don't support the full path. To try it on a model that's already in use, make a copy with Use as Template, test the copy, and switch only if both calls work.

Test It — each model assigned to an environment shows a Test It button. It sends a simple request the way a workflow in that environment would, confirming the environment can reach the model. Use it after assigning a model, or when diagnosing why a workflow isn't reaching a model. A successful test shows the model's response; a failed test shows the error returned.

An org can have multiple environments. Common patterns:

A thunk (workflow) is linked to one environment at a time. Moving a thunk between environments (e.g., from staging to production) means reassigning its environment reference.

Only the org owner and org admins can create, update, delete, or configure environments.

Org owners and admins automatically have access to all environments in their org.

Everyone else — thunk owners and other admins — must be explicitly granted access to an environment by being added as a Member of that environment, which only an org admin can do. This allows orgs to maintain strict separation between environments (e.g., only the infrastructure team has access to the production environment).

The org owner/admins can grant/revoke a user's membership on an environment at any time.

In addition to org-managed environments, every user has a personal environment. This is an isolated context that belongs to the individual user — the org does not provision or control it.

The personal environment surfaces the platform-level AI models (provided by Thunk.AI) for personal use. Users experimenting or building individual automations use this environment. When a user is ready to promote a thunk to a shared org environment, they reassign its environment reference.

On a private instance, users and groups can be synced from Microsoft Entra ID, Okta, or another SCIM 2.0 provider, and access can be granted to a group instead of to individuals. See Sync user groups from your identity provider. The OAuth credentials that models and connections use are managed as described in Manage OAuth credentials and authorized thunks.