Workspace defaults

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.

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 and the Act for your users 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 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.

Choose what your team hears when something goes wrong

“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 either way.

See When the outcome is unknown and 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.
• 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.

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

{
  "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:

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 }'

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 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: decidedBy on a policy, and the approval window.
• Workspace and end-user connections: acting in your users’ own accounts.
• Notifications: the channels and alert types.
• Audit records: the workspace.defaults_updated record.