Secrets and key vaults
Passwords, tokens and keys as a named secret nobody reads back, in Flow's own vault or in the one of your own cloud.
In Flow a secret is a thing with a name, such as crm-api-key, with versions, an expiry date and who may use it. Once saved, nobody can read a value back, not even the owner. Connections, API policies, AI keys and webhooks refer to it with secret:name; where the value lives is up to the environment. So the same workflow reads Test's vault in Test and Production's in Production.
In short
Named secrets with versions
A new version is used at the next call, without a restart; you switch an old version off.
Never read back
No screen, API or AI app gives a value back, and Flow masks it in logs, runs and answers.
Your own vault
Azure Key Vault, AWS Secrets Manager or Google Cloud Secret Manager, signed in with the environment's own identity, without a stored password.
An owner decides
Choosing another vault is a proposal only the organisation's owner approves, and it is recorded.
Visible in the security overview
Expired, expiring, too widely shared and unused secrets are reported, and you see which are read most, with a link to the secret.
AI apps ask, people fill in
An AI app only sees names and can request a secret; a person types the value in the studio.
What you can do
Keep a secret in the vault
Under Security → Secrets you create a secret, give it a version and see where it is used and who read it. In a connection you choose the secret instead of typing the value; if you type a value anyway, it becomes a named secret.
Use the vault in your own cloud
In the portal, on an environment's Secrets tab, you choose where its secrets live. The portal shows exactly what to set up in Azure, AWS or Google Cloud, tests the connection and guides the move; an owner approves it.
A key of its own per environment
Every environment encrypts what it stores with a key of its own. You make a new key in the portal; the environment re-encrypts everything at the next start, without you setting anything again.
The guides
Keep secrets in a vault
You store a key or password once, with a name, in your environment's vault. Connections and workflows refer to that name; Flow never shows the value again, not even to you. A new key becomes a new version, used at the next call without a restart. In this guide you create a secret, use it in a connection, add a version and see who read it when.
Reference: secret references
Wherever Flow asks for a secret, you refer to it by a name, never with the value itself:
Your own key vault (Azure, AWS or Google Cloud)
Passwords and keys Flow uses are kept encrypted in Flow's own vault by default. If you want to keep them in your own cloud, in Azure Key Vault, AWS Secrets Manager or Google Cloud Secret Manager, you choose that per environment in the portal. Workflows refer to a secret by its name; which vault looks that name up is up to the environment. So Test reads Test's vault and Production reads Production's, with the same workflow. Another vault is an access change: an owner approves it, and Flow never copies values — you put them in the new vault yourself.
Identity between Flow and your cloud
A vault in your own cloud (Azure Key Vault, AWS Secrets Manager, Google Cloud Secret Manager) needs a key of its own to get in. Putting that key in Flow as a password only moves the problem. That is why every environment has an identity of its own, issued by the portal: you trust exactly that identity in your cloud and give it read access. Flow then gets a short-lived token each time, and no secret is stored anywhere. You see where the portal shows that identity and what you set up per cloud.
Encryption: your environment's key and renewing it
Passwords, tokens and keys you store in Flow — of connections, API policies, signing and dashboards — are kept encrypted in the database. For that every environment has a key of its own, made and kept by the portal and never shown to anyone. In this guide you see where that key is, renew it, and see how the environment re-encrypts everything without anyone having to set anything again.
Create and test an HTTP connection
A connection records another system's address and key once, for the whole workspace. Workflows and AI Colleagues use it with just a path; the key stays encrypted on the server. In this guide you create a connection with a bearer token, test it with one call and see that the key can never be read back.
What a connection may do: read, drafts, write
Every connection has an allowed access. Read only lets only GET through, Prepare drafts everything except DELETE, Read and write everything. Flow checks this itself, before the call leaves — even when a workflow or AI Colleague tries something else. Here you see a POST refused, then allowed, and a DELETE that is still not allowed with Drafts.
Replacing a secret while others work
You do not replace a key at night when nobody works: it happens while colleagues run workflows and update connections. A new version applies from the next call, also in a workflow that is already running; a version you switch off is no longer used anywhere. The list of connections says which secret no longer works, and when a colleague works on the same connection at the same time, both their change and yours are kept. Below you see both people's screens side by side.
Microsoft 365: connect and send an e-mail
A connection with Microsoft 365 gives workflows and AI Colleagues building blocks for Outlook mail and calendar, Teams and OneDrive/SharePoint. You connect an app registration from Microsoft Entra ID, test the connection and send an e-mail with the building block Outlook · Send email. You need: the tenant ID, client ID and client secret of an app registration with the application permission Mail.Send.
E-mail over SMTP: connect and send
Not every mailbox lives in Microsoft 365. With the connection E-mail (SMTP/IMAP) Flow sends from any mailbox that speaks SMTP — a hosting package, your own mail server. You fill in the server, port, security and an (app) password, test the sign-in and send an e-mail from a workflow. You need: your mail provider's SMTP details.
Connect an MCP server and call a tool
More and more services offer their functions as an MCP server (Model Context Protocol): a list of tools with a name, a description and arguments. Flow connects such a server as a connection; its tools become steps in workflows and tools for AI Colleagues. Tools that change something only work when the connection may write. You need: the MCP server's address (Streamable HTTP, usually ending in /mcp) and possibly a key.
More that is new
The new portal
Calmer: one question per screen, four fixed places in the bar, and your personal Flow always first.
Governance
Quotes, projects, people and decisions in one place next to Flow, with gates, four eyes and a decision ledger you can have checked.
AI Colleagues build what is on the Board
Let an AI Colleague build an item that is ready: you approve the plan, follow it live and a colleague reviews the result.
The Board
The work from idea to done on one board, with cards that say what is still missing.
Dashboards
Everything your tables and workflows produce, at a glance, built the way you will see it.
The company home
One place where everyone starts the day: in your house style, with what matters to each role.
Security you can see
Who can open what, and why, explained in plain words everywhere in Flow.
RPA screenshots
See what the browser saw, right where you follow the run.