The bots do the work. You watch.

What it does

Four bots ship with the product, and the SDK is there to write more.

And above all: when it breaks

That is where an automation tool is judged. A bot that works asks nothing of anyone.

• The screenshot at the moment of failure. What the browser had on screen when the bot stopped — not a page reloaded ten minutes later, once the problem had gone.
• The Playwright trace, to reopen in the official tool: every action, every wait, the DOM tree at each step.
• The exact parameters it started with, and the full log.

Two hundred messages, three faults

The insights screen answers one question: what breaks most often, and since when.

• Messages are grouped by cause. Addresses, numbers and identifiers are replaced by markers: two hundred unique lines become the handful of faults they actually are.
• Each group keeps a real example under its signature, along with the period over which it was seen. A cause from a month ago is not handled like one that appeared this morning.
• Success rate, median duration, 95th percentile — and the period exports to CSV.

At the scale of an organisation

The same entity and rights model as Tick&, for the same reason.

• Isolation is enforced by PostgreSQL, through Row-Level Security — not by WHERE clauses one can forget to write. Integration tests check it against a real database, and they all fail when pointed at the owner role.
• A right is a triple of object × action × scope, and a missing row means refusal.
• Each bot is made available per entity and per profile. The entity says where it may run, the profile says who, there, may launch it.
• LDAP and Active Directory accounts, with group → profile + entity assignment rules. The local database is queried first: a break-glass administration account is never locked out by an unreachable directory.

Five accounts, five scopes

The demo is seeded with five accounts, all sharing the password flow. Each one illustrates a case the model has to handle — and on Flow&, isolation covers two things at once: what an account sees of the organisation, and which bots are open to it.

• sophie — Supervision on Pôle Industrie, recursive. Sees the whole branch and everything below it, its executions and its figures, without a glimpse of Siège. Three bots are open to her. The account to try first: the one that shows the most without being an administrator.
• admin — Administration on Groupe Vercors, recursive. The full tree and the configuration screens: entities, profiles, rights, bot availability rules, API keys and plugins. The only one who sees “Espace connecté”, and only when standing on Siège — the rule that opens it names an entity and a profile.
• thomas — Operator on Site de Lyon, non-recursive. One entity, without its descendants, and nothing but that entity's executions. The difference with sophie is what recursion changes.
• lea — Operator on Site de Saint-Étienne and Observation on Siège. Stacked authorisations: rights follow the active profile, never the union of both. Switching context at the top of the screen changes what she sees — and the available bots change with it.
• marc — Observation on Groupe Vercors, recursive. Sees everything, launches nothing: the profile has no execute right. The account of the manager who follows the figures without touching production.

No sign-up, no data collected. Everything resets on the hour — launch it, break it, delete it. The four bundled bots have no free-form parameter: you cannot make the server visit whatever you like. The Tick& demo is next door.

None of the bundled bots takes an address

That is not an oversight, and it is the most important detail in the whole set of examples.

• A bot that opens whatever address it is given turns the server hosting it into an open relay — towards its internal network as much as towards any third-party site, from its IP address and under its domain name. It is the first thing that breaks on an instance open to everyone.
• The four bundled bots have closed parameters only: enumerations, booleans, bounded integers. Three visit sandboxes published for that very purpose — never a site that did not ask for it. The fourth does not leave the machine at all: it serves its own page.
• The constraint lives in the bots, not in the demo configuration. A refusal placed elsewhere would have protected only the demo, and left the trap open for anyone writing their first bot by copying ours.

On your own servers

In containers or without, on Linux and on Windows Server. Nothing leaves your machine.

• The installation guide covers the secrets to generate, the mandatory rotation of the application role's password, backups and upgrades — docs/23-installation.md .

Where the project stands, said plainly

0.3.2 is out. Here is what you should know before using it.

• Never used in production by anyone. The container installation path was walked on a clean machine, and the four defects found were fixed in the code — but no organisation has yet run real bots with Flow&.
• The container-free installation paths have not been walked, neither on Linux nor on Windows Server. A blocker there is expected, and reporting it is the most useful contribution to the project today.
• The major version is zero: a minor release may break things, and the changelog says so. Both SDKs — bots and plugins — are in the same position.
• A plugin runs inside the API process, with its privileges. There is no sandbox: installing one commits as much as deploying a release.