Flows and AI
Write the journey; get a flow you can edit and run
A flow is a graph of roles, steps and the records they touch. Draw it from a sentence, from a role’s permissions, or by clicking endpoints, then let Journey Lanes fill in how each call works.
Flows from a description
Write who signs in, what they see and what they can do. Each role becomes a lane, each action a step that calls a real endpoint from the scan, and a system lane shows the records each step touches.
“A company admin logs in. The company admin sees the users and can create a user. An employee logs in. The employee sees the products and can order a product and update their order.”
- Company Admin
POST /realms/portal/protocol/openid-connect/token - Company Admin
GET /api/users - Company Admin
POST /api/users - Employee
POST /realms/portal/protocol/openid-connect/token - Employee
GET /api/products - Employee
POST /api/orders - Employee
PATCH /api/orders/:id
- Descriptions of up to 30,000 characters. The rules engine reads English, Dutch and German, including negations (“should not be able to delete”) as steps that must be refused; Claude reads any language.
- Flows get the checks the description promises: “only sees their own companies” becomes a check on the response, “cannot create a company” a step that must answer 403.
- Sentences the engine can’t turn into a step are named in a warning rather than dropped.
AI, and what happens without it
On this installation, Claude by Anthropic drafts flows from longer or looser descriptions, sets up calls with “Help me” and explains failed steps. Each of these is an AI request, and only happens when someone asks for it.
Each plan includes a monthly number of AI requests: Personal 100, Team 500 and Business 2,000. There is also a rate limit per organization.
Past a limit, or when Claude can’t be reached, the rules engine answers instead, with a sentence saying why: descriptions are still drawn, and “Help me” and “Explain this failure” still read what the code declares. Nothing fails because AI isn’t available.
What is sent to Anthropic, and when, is in the privacy policy.
Tours per role
Pick one of the roles the scan found. The tour shows each kind of record that role may work with, with its actions underneath, and adds up to five things the role may not do, each with a check that the call is refused. Inherited roles count, such as Symfony role hierarchies.
Deletes are never part of a tour, so running one never removes data. Endpoints decided at runtime by a voter or an expression are left out and named.
Building by hand
- Endpoints menu: every scanned endpoint by collection and path, with GET, POST, PUT, PATCH and DELETE in that order, and a search box. A click adds it after the selected step, in its lane.
- References: paths, bodies and headers can use values from earlier replies (
{{create-company.id}}) and the run’s own values:{{run.id}}for names that must be unique,{{run.password}}for an account the flow creates. - Undo and redo cover every change to a flow; removing a step takes the remove button, never Backspace, and the steps around it are reconnected.
Help me
On any step that calls an endpoint, “Help me set up this call” reads the code behind it: the file that defines the endpoint, the processors, controllers, validators and services it uses, and the frontend page that calls it. It proposes, and nothing changes until you apply it:
- a body that passes the endpoint’s validation, with every required field;
- the path keys, filled from a record an earlier step created or from a list step it offers to add;
- the query options the endpoint supports: pagination, filters and sorting;
- checks for the answer, and notes such as the role needed and side effects.
Explain this failure
A failed step of a finished run has “Explain this failure”. It says why the step failed and where the cause is (the flow, the code or the environment), points at the lines or the reply that show it, and proposes a change to the step that one click applies and can be undone. When the cause is in the code, it shows what to change there as a snippet to copy; Journey Lanes never changes your code.
- Only this step, only this project. The request carries no text from the person asking. The server assembles the prompt from that run and the project’s own sources: the step’s setup, its result as run history keeps it, the steps before it, the environment’s sign-in type, and the code behind the endpoint.
- No credentials. Run history holds none, and anything that still looks like a key or token is masked again before it goes out. The environment’s address is left out.
- A fixed answer, not a chat: summary, cause, evidence, step change, code changes and notes.
- Editors only, and at most 30 explanations an hour per project. It only runs on the button, never by itself.
Saved roles and reuse
Every role in a project’s flows is kept with the steps that sign it in, such as the login and a “who am I” check. Start a new flow with any of them, or add one to an open flow; because a saved role keeps its id, the test accounts on your environments apply as they are.
Flows can be duplicated, steps copied from one flow into another, and whole flows exported and imported as files (see exports).
Draw your first flow
Describe one journey and run it against the mock backend.