Management
Versions, access, runs, inbox, traffic, problems.
Compare two versions
In Version control every committed version is in the history. You pick a version, see which items changed in it and compare one item line by line with the version before. That is how you find out afterwards when a rule or setting changed, and who changed it.
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 inbox: approve a run
Some decisions you do not want to leave to a workflow. With the Human review step a run waits until someone has looked at the data. That run is then in the inbox, under Runs. You read what to check, briefly record why, and approve or reject. The workflow then carries on by itself.
Live traffic: who calls your APIs?
Under Live traffic you see every call to your APIs as it comes in: which endpoint, which status code, how long it took and with which key. That way you see at once whether a consumer gets through, or keeps being refused.
Where is this used? Dependencies
Before you change a table, workflow or API, you want to know what relies on it. Where used? tells you per item: which workflows, endpoints and agents read or write it. The Dependencies map shows the same for your whole environment, across modules.
The data graph: how your data hangs together
The data graph draws your tables and knowledge bases with their columns and rows, and the relations between them. Flow finds relations itself, from the names of columns and the values in them. You confirm or reject them, so workflows and AI Colleagues know which data belongs together.
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.
Workspace and audit log
Under Workspace & audit you see with which role and permissions you work in this environment, what the platform can do, and the audit log: every change, test, publication and review, with who did it and when. Handy when you want to know why something works differently from yesterday.
Export and import a whole environment
With Export everything you keep the structure of your whole environment in one file: every module with its tables, workflows, APIs, agents and building blocks. With Import you put such a file into another Flow, for example the personal Flow of a colleague who wants to try things out — all of it, or only the modules they choose. Data, connections and secrets never travel, and nothing is ever overwritten.
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.
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.
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.
Changing roles while someone works
You change a role or take someone out of the organisation in the portal, under People — also when that person is working in the studio at that moment. Flow does not wait for the next sign-in: the open studio follows at once, says in one calm notice what changed and only shows what the new role may do. Someone who was taken out of the organisation sees a plain page that says so. Every environment hears it, in the right order. Below you see the owner's portal and the colleague's studio side by side.
The board
On the board you follow the work from idea to done. An epic is the big goal, a feature a recognisable part of it and an item the work itself: items move across the columns New, Grooming, Refined, Committed, In progress, Review and Done, and epics and features follow their items by themselves. You create them, move a card with the mouse and with the keyboard, see what Flow says when an item may not move on yet and fix it on the spot. You read an item calmly in the inspector's tabs, or large as a page. Then you choose which items a new version delivers, and see the same items again on the release in Acceptance. Finally an AI app works on the board over MCP. Finally you write an item well: a user story from a template, expanded in the large editor, with a proposal from the AI help that you accept.
An AI Colleague builds an item
An item on the board that is ready can be built for you by an AI Colleague. With ‘Build this item’ the AI Architect gets the item as its assignment: title, description, acceptance criteria and what it belongs to. It first proposes a plan, part by part; only when a person approves the plan does it build, with your rights and only in the development environment. You follow every step in the item, every built part becomes a version linked to the item, and when it is done the item moves to Review with a report. Approving is always done by a person who did not work on it. An AI app can also put an AI Colleague to work over MCP and follow it.
Together on the Board
On the Board a team works at the same time. When a colleague moves a card, comments or adds an item, you see it at once on your own Board, and Meanwhile says who did what. When you move a card a colleague just put somewhere else, Flow does not quietly move it back: you see who moved it where and decide yourself whether it stays. And when a colleague applies a template while you type the description, your text stays and Flow asks at the field which text stays.
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.
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.
Approve what Claude Desktop proposes
An AI app such as Claude Desktop builds what is versioned in Flow straight away. Access it does not: a role for a colleague, a team, a group from your sign-in system, a share link, a key or an accepted risk the app proposes. Under Proposals you read why the app wants it and what then happens, and you decide: approving carries it out with your rights, rejecting tells the app why. A key or link only you see, once. If the app needs a secret, it asks for it and you type the value: it goes straight into the vault. What your own app proposes about access, a colleague approves: four eyes.
Deciding on proposals together
An AI app never changes access itself: it proposes, a person decides. When two owners look at the proposals at the same time, one decision stands. The card with the other says by itself who decided and when, and whoever is just too late hears who was first — instead of ‘someone else’. Below you see both owners' screens side by side.
Mirroring the Board to Jira
When a team works in Jira, it can read along with the Board there. Flow leads: what you do on the Board appears in Jira; what someone changes in Jira does not come back and is overwritten the next time. That way there is one truth. You make a connection with a service account that may write only that one project, set up the mirror, let Flow suggest the statuses from the project's workflow and switch it on. Then every card shows whether its copy in Jira is up to date. A story that was in Jira already, you bring over to Flow from the Board's Jira tab.