Security you can see
Who can open what, and why, explained in plain words everywhere in Flow.
One access decision holds for every way in: the studio, the home, dashboard buttons, the chat, MCP and the API. And you do not have to take it on trust. Flow shows per item who can open it and why, points out what is open or weak, and keeps every refusal in the audit log.
In short
Who can see this?
Per dashboard, AI Colleague, workflow, table or knowledge base: who can open it, through which role, team or group, and who has it in the menu but cannot open it.
The security overview
Flow points out what is open or weak, explains why and takes you to where you fix it. A critical risk holds back publishing.
People, teams and groups
Give roles directly, through a team in Flow or through a group from your identity provider, such as Entra ID.
Two-step verification
Building needs two-step verification or single sign-on, and your recovery codes are in your profile.
AI Colleagues with your rights
An AI Colleague starts workflows with the rights of the person chatting, never with those of the builder.
Everything on record
Every refusal and every view through an open link is in the audit log.
What you can do
Classify your data and set requirements
Mark a table as confidential or sensitive, and Flow carries that classification through every workflow, API and AI Colleague that uses it. Requirements say who may start what.
See who can open what
Open any item and ask who can see it. Flow answers in plain words: through which role, team or group from your identity provider, and who sees it in the menu but cannot open it.
Follow up on the security overview
Sensitive data open to everyone, open links without an end date, buttons that change data without confirmation, builders without two-step verification: the overview lists them with an explanation and the way to fix them.
People, teams and Entra groups
Invite people in the portal, give them a role, and let the groups in your identity provider decide who belongs to which team.
Two-step verification and recovery codes
Secure your account with a second step, keep your recovery codes in a safe place, and make new ones in your profile when you run low.
Answer what colleagues tell you
Colleagues give feedback from the home: a thumb on an AI Colleague's answer, or a screenshot with what must not be sent blacked out. Read it in the Feedback inbox, reply in their home (never by mail) and turn a bad answer into a test case.
Your cloud trusts your environment, not a password
Every environment has an identity of its own, issued by the portal. Trust it in Entra ID, AWS or Google Cloud and give it read access on your vault: Flow gets a short-lived token each time and stores no secret for the vault anywhere.
Your secrets in your own key vault
Choose per environment where the values of secrets live: Flow's own vault, Azure Key Vault, AWS Secrets Manager or Google Cloud Secret Manager. Workflows refer by name; an owner approves the switch, and Flow never copies values — you put them in the new vault yourself.
The guides
The security model: classification, visibility and requirements
Flow does not secure per screen but per item: a table knows how sensitive its data is, a workflow says what a caller must bring, and an endpoint may only make security stricter. In this guide you create a table with personal data, a workflow that reads it, and you see an endpoint with too few rights being refused — and how to put it right.
A table's security
On a table's Security tab you set how sensitive the data is, whether other modules may use the table, and who may read and change the rows: per role, and separately for consumers through the API and for workflows. You protect a table of customer details.
Who sees this?
For every dashboard, AI Colleague, workflow, table and knowledge base you ask Flow who can open it, and why: which role, and how someone has that role (directly, via a team or via a group from your sign-in system). You also see who has it in their menu but cannot open it. The answer comes from the same access decision the server makes at every opening: what the panel says is what happens.
Your team and their roles
In the portal you invite people to your organisation, each with a role. A builder builds in Development and publishes up to Acceptance; a colleague uses what has been built and tests and approves; the owner manages everything. You see per environment what a role may do, and how your colleague gets in.
Create a role of your own and give it
A role is a bundle of permissions: what someone may see and do in this environment. Flow has fixed roles, such as Developer and Reviewer; which fixed role someone has follows from their role in the portal. If none of them fits, you create a role of your own with exactly the permissions needed — and no more — and give it to a colleague. The server checks those permissions on every request.
The security overview
What is open or weak in how your Flow is set up? The security overview finds out for you: open links, menus that show confidential data to everyone, workflows without requirements, keys without an end date, builders without two-step verification. Every finding says why it matters and opens the place where you fix it with one click. Before the home goes live, the same check looks along: something critical stops the publishing.
Follow up on security advice
Flow checks your environment continuously: keys that never expire, tables open to everyone, APIs with too generous a limit. Under Security advice you see every finding with why it is a risk, which standard it belongs to, and usually a button that fixes it for you.
A security policy on an API
A security policy says who gets into an API: with which sign-in method, with which permission and from which network. You create it once and hang it on one or more APIs. Every endpoint of those APIs inherits it and may only make it stricter.
People and teams
Under Administration → People you see who gets into this environment, with which role, and how each person got that role: directly through the portal, through a team, or through a group from your own sign-in system. You make a team, give it a role and put people in it: everyone in the team gets that role as well.
Groups from your sign-in system (SSO)
With single sign-on your own sign-in system, such as Entra ID, decides who gets in. Map one of its groups to a role in Flow, and everyone in that group gets the role when signing in; whoever leaves the group loses it the next time. You require two-step verification for everyone without SSO, test which roles a set of groups gives, and see a colleague arrive with her group.
People: change roles and remove someone
Under People you manage who works in your organisation. You make a colleague co-owner, revoke an invitation that is no longer needed, and take someone out of the organisation. You also see what that means for that person. Where everything is in the new portal, you read in ‘The new portal: where to find what’.
Identity management and single sign-on
Who may get in, and who decides? With single sign-on your own identity provider decides (Entra ID, Google, Okta, Keycloak …): whoever leaves there can no longer get into Flow either. You connect the provider to your organisation in the portal, under Security and sign-in, and see how a colleague on your domain is sent there when signing in.
Your account and your organisation
You create an account in the portal, secure it with a second step, and set up an organisation. You then have three environments — Development, Acceptance and Production — each its own Flow with its own database. You need an authenticator app on your phone (for example Microsoft Authenticator or 1Password).
Your profile: password and recovery codes
Under your avatar at the top right you manage your own account. You change your password, sign out, and sign in again with the new password and a recovery code, as you would when your phone with the authenticator app is not at hand. Then you see how many recovery codes you have left and make new ones.
Answering feedback
Colleagues give feedback from the home: a thumb on an AI Colleague's answer, or through the Feedback tab with a screenshot on which they mark something and black out what must not be sent. In the studio you read it all in the Feedback inbox, reply (the reply reaches the colleague in their home, never by mail), keep the status up to date and turn a bad chat answer into a test case, so it does not happen again.
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.
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.
More that is new
The new portal
Calmer: one question per screen, four fixed places in the bar, and your personal Flow always first.
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.
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.
RPA screenshots
See what the browser saw, right where you follow the run.