Choose who an agent or flow acts as
This is the setting that lets you hand an agent real access without losing track of it. Every pairing of an agent or flow with an integration names one account its calls run as - the team's, the individual's, or a credential your API supplies per call.
That choice is honoured absolutely: if the named account is missing, the call does not happen and the reason is on screen. It never quietly borrows a different identity to get the job done, which is what makes "who did this?" a question the session can always answer.
The four identities
| Identity | Whose credentials | Typical use |
|---|---|---|
| Team account (the option is named after the domain - Customer Support) | The connection owned by the agent or flow's domain, managed by domain owners. | Everything that uses a stored credential. |
| The person using it | Each person's own sign-in, with the domain connection's settings and enabled tools. Agents only. | A shared agent that sends from each member's own mailbox or calendar. |
| API caller | A credential supplied on each API fire call, scoped to that one execution. | Multi-tenant products calling Yekar.AI on behalf of their own customers. |
| Platform (managed by Yekar.AI) | A Yekar.AI-managed installation, gated by your organization's install. | Yekar.AI-provided capabilities such as web search. |
Platform is assigned by the system where it applies - it is not an option you select. API caller has nothing to connect in the UI; the credential arrives on the call and is never stored as a reusable connection (see Caller credentials).
The person using it
One thing has to be true before an agent can act as a member: the member signs in - once per integration, for the whole organization - from Integrations with My account selected under Acting as, or from the link an agent shows them. A person's sign-in is used only by turns they run themselves.
Nothing is needed from a domain owner first. Personal sign-in is on by default in every domain, including for an integration the domain has never connected. An owner can turn it off per integration under Personal sign-ins on the domain's page for it, whether or not a team account is connected there. Where the domain does hold a connection, it keeps supplying the settings and the enabled tools; only the credential is the person's. An integration that declares a required setting (a base URL, for example) still takes it from the domain's connection, so an owner sets that once before anyone can run it as themselves.
Each binding also carries a choice for a person who hasn't signed in: Fail if they haven't signed in (the default - the tool fails with a sign-in link and never touches the team account) or Fall back to the domain (the option is named after the domain whose account would step in; the team account is used, and the conversation says so).
Either way the agent is still usable before anyone signs in. A banner above the composer names the integration and links the fix, and nothing blocks the first message.
On a schedule or trigger, an agent bound this way runs as the person who created the trigger, as long as they are still a member and signed in. Otherwise the fire is skipped and the trigger's run history says why - a departed creator never stops a schedule silently. Disabling a member removes their sign-ins; leaving a domain, or an owner closing the door, removes nothing.
A domain with one member - yourself - still works, and a team account there needs no per-member sign-in.
On a plan that permits a single domain there is no team-versus-personal choice at all: every connection belongs to your organization, the Integrations screen shows no "Connected for" filter or "Acting as" switcher, and agents offer no The person using it option. This follows the plan's ceiling, not how many domains you have created - an organization on an unlimited plan keeps the choice from its first domain onward.
Where you set it
- Flow: open the Flow, select ⋮ → Connections, and use Runs as for each derived integration.
- Agent: the Integrations drawer shows each derived integration's identity under Runs as and lets you switch between the domain's team account, The person using it, and API caller.
- Yourself: Integrations, then the integration, then My account under Acting as - where you sign in for every agent set to run as you.
Unattended work and API caller
Team account and Platform are always safe to run unattended: their credentials are stored, so nobody has to be present at 8am on a schedule.
API caller depends on what you choose under If no credential is sent. Fall back to the domain is unattended-safe - a scheduled run simply uses the domain's credential. Fail the run (credential required) is not, because nobody is there to supply a token: a schedule or event fire of it is skipped and recorded as such.
The person using it runs unattended as the trigger's creator. With Fall back to the domain a fire always runs (as the creator when they are signed in, as the team account otherwise); with Fail if they haven't signed in a fire is skipped - person_unavailable in the run history - when the creator is no longer an active member of the domain, has not signed in, or an owner has turned personal sign-in off for that integration in the domain.
Credential precedence
Within the one identity an execution acts as, the credential is chosen in a fixed order - never across identities:
- A caller-supplied credential wins outright. When an API fire call carries one, it replaces the stored credential entirely for that execution - a partial caller credential never borrows the missing half from the stored account, and an expired caller token is never silently replaced by a stored one.
- Otherwise, the connection's default credential runs. An owner can hold several named credentials per integration (
Production,Staging…); the one marked default is used unless something explicitly selects another (a Flow test run can pick a named credential). - With no default flagged, the most recently updated credential runs. The pick is integration-owned logic, so an integration with a stronger notion of "current" can refine it.
What never happens: a fallback between identities that nobody chose. A team-account agent or flow with no domain connection fails with SERVICE_CONNECTION_MISSING rather than reaching for anything else; an API-caller binding set to credential required fails with CALLER_CREDENTIAL_REQUIRED; a person binding whose person has not signed in simply has no tools from that integration for this turn. And no policy reaches through a closed door: while a domain owner has personal sign-ins switched off, even a binding set to fall back does not resolve, because that switch is the owner's decision and a policy that could reach past it would make it mean nothing. Each execution acts as exactly one identity, and the run records which credential source served it - personal, caller, or stored for a fallback.
Tips
SERVICE_CONNECTION_MISSING means the team account with no domain connection; CALLER_CREDENTIAL_REQUIRED and CALLER_CREDENTIAL_EXPIRED mean the API caller must supply a (fresh) token; EXECUTOR_AGENTS_ONLY means a person binding reached a flow, which can only run as its domain.
A person binding that cannot resolve does not produce an error code - it is a state, and the product says so before anything fails. A banner above the composer names the integration and links the fix: "This agent runs as you for yekar.gmail, and you haven't signed in" when it is your sign-in that is missing, or "A domain owner has turned off personal sign-in for yekar.gmail" when an owner has shut the door. The agent's own answer says the same thing, because its tool list is built from the same resolution. See Troubleshooting and Caller credential errors.