> ## Documentation Index > Fetch the complete documentation index at: https://docs.usefused.com/llms.txt > Use this file to discover all available pages before exploring further. # Share access with teams > Give a team exactly the services, buckets, and apps it needs — and nothing else. Access in Fused is granted per resource, not per person's good intentions. A team can be allowed to *use* a bucket-backed app without being allowed to read what is in the bucket. This page covers granting that access and checking it before you need it. ## Roles and grants A workspace role sets the baseline. Grants narrow or extend it per resource. Every one of these commands takes the same three things in the same order: **the team, the resource, then the level.** The command words are fixed; everything in `` is yours to fill in. | Command | Team | Resource | Level | | --------------------------- | ------------------- | ---------------------- | ---------------------------------------- | | `team access workspace set` | `` | — | `owner` · `admin` · `builder` · `viewer` | | `team access service grant` | `` | `` | `use` · `manage` | | `team access bucket grant` | `` | `` | `use` · `manage` | | `team access app grant` | `` | `` | `read` · `use` · `manage` | Swap `grant` for `revoke` to take access away, with the same three arguments. The workspace role is `clear` rather than `revoke`, and it takes no level: `team access workspace clear `. So for a team whose slug is `payments`: ```bash theme={null} fused-cli team access workspace set platform admin fused-cli team access service grant payments stripe use fused-cli team access bucket grant payments prod-credentials use fused-cli team access app grant payments app_7f31… read ``` Activation permissions come with Admin and Owner; Builder and Viewer do not carry them. What each level actually buys: | Resource | Level | Permissions it carries | | -------- | -------- | ---------------------------------------------------------------------------------------- | | Service | `use` | `service.read`, `service.consume` | | Service | `manage` | The above plus `service.manage` | | Bucket | `use` | `bucket.read`, `bucket.use` — select the bucket for an app, without seeing what is in it | | Bucket | `manage` | The above plus `bucket.values.read`, `bucket.manage`, `credentials.*`, `connection.*` | | App | `read` | `app.read` — it shows up in listings, nothing more | | App | `use` | The above plus `app.use` — actually call it | | App | `manage` | The above plus `app.manage` and `app.tokens.manage` | App levels apply to every version of that app. Bucket `manage` includes `bucket.values.read`. That is the line this whole page exists to draw — `use` lets a team build on a credential they can never read, and `manage` hands them the credential. Grant `use` unless someone genuinely needs to administer the secrets. App grants need the ID from `sdk list` or `mcp list`, not a name. One `app` command covers both kinds, so it cannot infer which you mean from a name they might share. ## Check before you plan Preflight the owning team against every dependency, so a plan does not fail halfway through on a missing grant. ```bash theme={null} fused-cli team eligible-owners fused-cli team build-access payments --resource service fused-cli team build-access payments --resource bucket fused-cli sdk plan --owner-team payments ``` `build-access` lists what is available to *both* you and the team — which is the set that will actually work. ## Share with the whole workspace When the audience really is everyone, a workspace-wide grant beats maintaining a grant per team. ```bash theme={null} fused-cli workspace access bucket grant shared-credentials fused-cli workspace access app grant app_7f31… fused-cli workspace access list --resource bucket ``` This gives every authenticated member and eligible owning team bounded *use*. Ownership does not move, secrets stay unreadable, and lifecycle and token management stay where they were. Revoke removes only that global binding — owner and explicit team bindings survive. A workspace-wide app grant does not replace the runtime token. Callers still need a valid execution token. ## Flags ### `workspace access list` | Flag | What it does | Example | | ------------ | ---------------------------- | ------------------------------------------------ | | `--resource` | Filters to `bucket` or `app` | `fused-cli workspace access list --resource app` | | `--limit` | Rows to return | `fused-cli workspace access list --limit 50` | | `--offset` | Rows to skip | `fused-cli workspace access list --offset 50` | ### `team build-access` | Flag | What it does | Example | | ------------ | --------------------- | ------------------------------------------------------------------------- | | `--resource` | `service` or `bucket` | `fused-cli team build-access payments --resource bucket` | | `--search` | Narrows by name | `fused-cli team build-access payments --resource service --search stripe` | | `--limit` | Rows to return | `fused-cli team build-access payments --resource service --limit 50` | ### `team member add` ```text theme={null} fused-cli team member add ``` | Flag | What it does | Example | | -------- | ------------------------------- | ------------------------------------------------------------------- | | `--role` | `member` (default) or `manager` | `fused-cli team member add payments ada@example.com --role manager` | ### `team create` | Flag | What it does | Example | | --------------- | ------------------------ | ------------------------------------------------------------------------ | | `--slug` | Sets the slug explicitly | `fused-cli team create "Payments" --slug payments` | | `--description` | Describes the team | `fused-cli team create "Payments" --description "Billing and invoicing"` | ## When you are denied Stop. Keep the config and plan you had prepared, and report the exact missing permission and resource. Do not self-grant, switch credentials, or retry with broader authority — a scoped `service.manage` grant does not include the workspace-level `workspace.update` that applying activation needs, so guessing tends to produce a second confusing failure rather than a fix. Access decides who may select a bucket. The bucket decides what credentials they get to use without seeing.