Connecting accounts
How a workflow gets into your CRM, your inbox or an internal portal, and what happens to the credential afterwards.
A workflow reaches a system with your permission and your credentials. There are two shapes that permission can take: a login you complete in a browser, or a key you hand over. Both happen in the interview, in the same conversation where you describe the work.
A login you complete
When the workflow needs to act inside a site you sign in to, the assistant shows you a login card. Open it, sign in, complete the two-factor step if there is one, and you land back in the console.
Your password goes into the login page, never into the chat. The assistant is told to use the card for exactly this reason and to never ask you to type a password into the conversation.
What that login creates is a signed-in browser profile for that workflow, not a row of text somewhere. It is registered with health checks and automatic re-authentication turned on, so an ageing session is refreshed rather than left to fail in the middle of a run months later.
If you close the card without finishing, or the attempt expires, the assistant notices when it checks the status and offers you a fresh one. It cannot see whether you succeeded except by asking, so tell it when you are done.
A key you hand over
Some systems are reached over their API instead of through a browser, and that needs a key or a token. Two routes get one into place.
You give it to the assistant. It stores the key against the system's name. The call that stores it has its arguments replaced with a redaction marker everywhere the call is shown: the run transcript, the run log, the activity preview. What comes back is a confirmation, never the value.
The assistant reads it off the page. After you have logged in and said yes, it can navigate your own signed-in browser to the settings screen, create or open the key there, and capture the value server side. It gets back a masked preview, the last four characters and a length, and nothing else. The value never enters the conversation at all.
Reading pages is something the assistant does on its own. Anything that changes your account, creating a key, flipping a setting, sending something, needs your explicit yes in the chat first.
Mailboxes are the special case of the first route. They are reached with an app password, a password the provider generates for one program, and it goes into the card rather than into the chat. When you save an app password the platform signs in to the mailbox once before storing it. If the sign in fails, nothing is stored and the card shows what the server answered, line by line, so you can correct the address, the password or the server name and save again. Email triggers lists the providers this works with.
Where the credential goes at run time
The workflow itself never stores a credential. It stores a reference to one, so the stored workflow stays safe to read, diff and hand around.
The value is resolved fresh, under your account, each time it is needed:
- A codified step that declared a connection receives it as an environment
variable named after the alias the step chose, for example
AA_CONNECTION_CRM. - An agentic run receives one variable per declared system, for example
HUBSPOT_API_KEY, and only for the systems that workflow actually declared.
Because that lookup happens per run, and not once when the workflow was written, rotating a key takes effect on the next run with no change to the workflow. A run that has been sitting on an approval for three days picks up the current credential when it resumes, not the one that was current when it paused.
Seeing and revoking
Settings has a Connected apps section, and it holds the keys your workflows use to reach the systems you work in: one row per system, how many workflows name it, whether it is connected or revoked, and a Disconnect button.
A browser login does not appear in that list, because it is not a stored key. It lives as a signed-in profile on that workflow's browser, and it is the site's own session, subject to whatever that site does with sessions.
Disconnecting flips the row's status rather than deleting it. The row stays in the list on purpose, because it is the record that the connection existed. When you reconnect the same system later, that row is reused and returns to connected, so disconnecting is never a one-way door.
What a disconnect actually does:
- A codified step that names that connection fails on its next run, before a sandbox is even created, and the failure comes to you.
- An agentic run still starts, just without that key. The agent finds it cannot sign in and says so.
Publishing checks the connection behind the trigger itself before it arms anything; other systems the workflow names are not checked at publish, a missing credential there shows up on the first run that needs it, with a notification. So connect what the workflow needs while you are in the interview, rather than meeting the gap on the first real run.