---
title: "Workspace defaults"
description: "Choose what your workspace does when no policy or setting decides: who approves a call made for one of your users, how long a request waits, and which problems your team hears about."
---

Workspace defaults answer the situations nothing more specific covers. A policy that says who decides always wins. When there is none, the default applies. One set of answers covers every environment in the workspace.

## Why defaults matter

Without them, two things are left to chance:

- **Who decides a call made for one of your users.** If your agent sends an email from a user's own Gmail and no policy names a decider, someone still has to say yes. The default makes that a stated choice: your team, or the user in your app.
- **What happens when nobody answers, a provider never confirms, or an account stops working.** The default decides whether your team is told, so a silent failure is a choice you made rather than one you discover later.

## Answer the setup questions

A new workspace asks these questions right after it is created, each already on its recommended answer. You can change any answer later in **Settings → Defaults**. An admin changes them. Every member of the workspace can read them.

### Who your agent acts for

**Me and my team**, **My users**, or **Both** (recommended). This changes no behaviour by itself. It decides which of the other questions the console asks.

If your agent acts for your users, the setup also asks where users land after connecting an account. That is the default redirect URL of your default environment, the same setting as **Integrations → Connect settings**. Other environments keep their own. See [Workspace and end-user connections](/execution/end-user-connections).

### Who decides a call made for one of your users

**Your team decides** (recommended), in **Approvals**, or **the user decides**, in your app. This applies when a call made with `Anlyon-End-User` needs a yes and no policy matched it. A policy with `decidedBy` always wins over this default, and a call made for nobody is always decided by your team.

The team is the recommendation because a person on your team sees every request in the console, while a user's request appears only in your app. When the user decides, the request stays out of your team's inbox and Slack, so your app needs a screen that lists and decides it. See [Let the end user decide in your app](/trust-control/approvals) and the [Act for your users](/guides/act-for-your-users#8-approve-in-your-own-ui) guide.

### How long a request waits

The console offers 1 hour, 4 hours, 24 hours, 3 days or 7 days. The API accepts any whole number of hours from 1 to 168. The recommended window is the service default, 24 hours.

The window applies to every approval of an action call, and to a custom approval that does not pass its own `expiresInSeconds`. When nobody answers in time, the request expires and nothing is sent. A governed call that builds its own [preview](/execution/previews) gets a preview that lasts as long as the window, and its approval never outlives that preview.

### Where your team hears about a request

Always in the console, and by email or Slack through the channels in **Settings → Notifications**. Those channels carry every workspace alert. See [Notifications](/account/notifications).

## Choose what your team hears when something goes wrong

| Situation | What happens | Your choice |
| --- | --- | --- |
| A call would go over an [impact limit](/execution/impact-limits) | It is refused before anything is sent, and your agent is told which limit stopped it. | None |
| A provider never confirms whether a call went through | The receipt stays `unknown` until evidence or a person settles it. Nothing is sent again. | Tell your team (recommended), or leave it in **Receipts** |
| One of your workspace's connected accounts stops working | Calls that need it are refused until it is reconnected. | Tell your team (recommended), or stay quiet |
| A user's connected account stops working | Their next call is refused with `409`. With a default redirect URL set, the answer carries a `connectUrl` to send them to reconnect. | None |
| Nobody answers a request in time | The call is cancelled and nothing is sent. | Tell your team (recommended), or cancel quietly |

"Tell your team" raises a workspace alert of type `outcome_unknown`, `connection_broken` or `approval_expired` through your notification channels. They are the same switches as **Settings → Notifications → Alert types**: switching one off there switches it off here, and "stay quiet" means no alert at all, not even an in-app entry. A request your users decide reaches your app as an `approval.expired` [event](/guides/webhooks) either way.

See [When the outcome is unknown](/execution/when-the-outcome-is-unknown) and [When the limit is hit](/execution/when-the-limit-is-hit) for what each situation looks like to your code.

## Rules no default can change

These hold whatever you answer:

- An API key never decides an approval it requested.
- Changing an impact limit or a budget needs a permission no key gets unless you grant it.
- An agent never loosens its own guardrails. Raising a limit, removing a budget or relaxing a policy from an API key, a CLI login or an MCP session waits for a workspace admin. See [Sign-offs](/trust-control/sign-offs).
- Account keys and tokens are used when a call runs and are never returned to your agent.
- Every call Anlyon accepts is recorded with a receipt of what it did.

## Read and change defaults over the API

The console reads and changes the defaults with these routes. They take a signed-in console session, not an API key: `GET` works for any member, and `PATCH` needs the admin role.

```bash
curl https://api.anlyon.com/api/v2/workspaces/$WORKSPACE_ID/defaults \
  -H "Cookie: better-auth.session_token=YOUR_SESSION_TOKEN"
```

```json
{
  "success": true,
  "data": {
    "actingFor": "both",
    "endUserDecider": null,
    "approvalWindowHours": 4,
    "effective": { "endUserDecider": "team", "approvalWindowHours": 4 },
    "recommended": { "actingFor": "both", "endUserDecider": "team", "approvalWindowHours": 24 },
    "setup": { "status": "completed", "at": "2026-10-26T09:12:44.000Z" },
    "updatedAt": "2026-10-26T09:12:44.000Z"
  }
}
```

A `null` answer means the recommendation is in force. `effective` is what applies after recommendations fill the nulls. To change answers, send only the ones you change. A field you leave out is kept, and `null` returns an answer to the recommendation:

```bash
curl -X PATCH https://api.anlyon.com/api/v2/workspaces/$WORKSPACE_ID/defaults \
  -H "Cookie: better-auth.session_token=YOUR_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "endUserDecider": "end_user", "approvalWindowHours": null }'
```

| Field | Values |
| --- | --- |
| `actingFor` | `team`, `users`, `both`, or `null` |
| `endUserDecider` | `team`, `end_user`, or `null` (the team) |
| `approvalWindowHours` | 1 to 168, or `null` (the service default) |
| `setupStatus` | `completed` or `skipped`, recorded with the time |

A request with no field to change answers `400`. A member without the admin role gets `403`.

## Find every change in the audit log

Every change that alters an answer writes one [audit record](/trust-control/audit) in the same transaction: `workspace.defaults_updated`, in the `access` category, with no environment. It holds who made the change, each changed answer before and after, what applied before and after (`effective`), and where it was made in `data.source`: `setup_journey`, `defaults_page`, `home_prompt`, or `api` when the request did not say.

## Related

- [Approvals and policies](/trust-control/approvals): `decidedBy` on a policy, and the approval window.
- [Workspace and end-user connections](/execution/end-user-connections): acting in your users' own accounts.
- [Notifications](/account/notifications): the channels and alert types.
- [Audit records](/trust-control/audit): the `workspace.defaults_updated` record.