Put the right work in the right hands.

No. Those systems keep owning their data. Flow reads the context it needs to make an assignment decision and hands a decision back. If you switched Flow off, your records would be where they always were.

Four things: your people, what each of them can do and at what level, when they are on shift, and what the work requires. Certificates and place access come with that. It is less than an ERP implementation and more than a spreadsheet, which is roughly the point.

By hard requirements attached to the kind of work. Skill at or above a level, a valid certificate, access to the place, and a shift covering the window with no absence booked over it. Failing any one of them removes the person from the list entirely.

If the time window is incomplete, availability cannot be checked, so the gate fails rather than waving the person through.

Three signals: how far the person's skill exceeds the minimum, how recently they confirmed the same kind of work, and how much is already assigned to them that day. You set the weights, the default is 50 / 30 / 20, and each ranking records the version of the weights it used.

There is a number from 0 to 100, and it is arithmetic, not a model. Every candidate shows the sentences behind it: skill level, days since similar work, current workload. If the number looks wrong, you can see which signal caused it and change the weight.

Yes, and it is a normal thing to do. Picking anybody other than the ranked first choice asks for a written reason, and the override is recorded with the leader's name. Overriding is never blocked, only recorded.

Flow says so, plainly, and lists every person with the reasons they failed. That list is usually more useful than a recommendation: it tells you whether the problem is a training gap, an expired card, or a shift you forgot to fill.

No, and that is deliberate. The floor screen is a web page built for a shared tablet in the hall. There is nothing to install, no account per worker and no password: a six-digit code belongs to the person, and the device is enrolled once by an administrator.

Three things today: see the work assigned to them for today and tomorrow, confirm a task done, and check their own certificates with expiry dates. Reporting deviations, attaching evidence and starting a timer do not exist yet.

Where an adapter exists for that system, yes, and only into the fields it already uses for assignee and status. Every integration ships read-only and stays read-only until somebody deliberately turns writing on. A pilot can run without ever writing anything.

Potentially none. Tasks, people and rosters can come in as files, which is how we would normally start. Connecting a source system properly is an adapter written against that system, and it is a decision to make after the first workflow has proved something.

In one installation for your organisation, with its own database and its own accounts, set up per customer rather than as a shared service. Hosting location is part of the pilot conversation, not a fixed answer.

What was recommended, who was eligible and who was not, which weights were live, who assigned, whether it was an override and why, and when the person confirmed. The audit trail is protected at the database level, not only in the application, so the application itself cannot quietly rewrite it.

English and Dutch today. The floor screen has to be in the language of the person standing in front of it, so adding another language is translation work rather than development work.