Building and documenting
From requirement to a package
ready to import.
The front for people who build: it turns a written requirement, a spoken one or a functional document into an iFlow, scripts, mappings, diagrams and documentation.
Not just a tool
The first interface is built together with your team, from a real requirement in your backlog. That is how the team sees where the tool is right and where it still has to decide — which is the point: the decision stays with whoever understands the business.
What is inside
Each capability, what it changes and why it is different
iFlow generator
From a description in natural language — written or spoken — to a complete BPMN2 package, with adapters, scripts and externalised parameters.
Gain · the skeleton of the interface stops consuming the first day of work.
What makes it different · it asks before generating what the requirement did not say. That is what prevents the plausible, wrong artefact — which costs more than having none.
FSD import
Reads the customer's functional document and turns it into a ten-section roadmap that feeds the generator.
Gain · the requirement written in prose becomes structure, and the gaps show up before the build.
What makes it different · each gap becomes an explicit question with its reason — instead of becoming an assumption hidden inside the artefact.
Artefact validator
Rejects what the tenant would reject, before upload, with rules taken from real customer exports.
Gain · the error shows up in your browser, not in the import that fails in front of the customer.
What makes it different · the rules come from measuring real artefacts — like the one that found 181 of 181 gateways naming their default route.
Improve with AI
Audits the package against fixed rules and applies the improvements you select, editing the file instead of recreating it.
Gain · fixing configuration stops being manual work repeated across thirty interfaces.
What makes it different · the edit preserves the artefact identity, so the package enters the tenant as a new version of the same iFlow — not as a duplicate.
Groovy, XSLT and mappings
Generates and reviews scripts, transformations and mappings from the description — and points out what breaks in production in what already exists.
Gain · takes away the repetitive part and leaves the decision with the consultant.
What makes it different · the review looks at the script in the context of the whole iFlow, not as a loose file.
Diagram Studio
Draws editable architecture and flow diagrams, from a prompt or from the iFlow ZIP.
Gain · the diagram for the presentation comes from the real artefact, not from what someone remembers of it.
What makes it different · the diagram is editable and versionable, not an image ageing in a project folder.
Doc Studio
Generates technical documentation from the real artefact in the tenant.
Gain · documentation stops being born out of date.
What makes it different · it documents what is deployed, not what the functional document said at project time.
Merge and Smart Propagation
Combines components across iFlows and carries a validated change to the interfaces sharing the same pattern.
Gain · reusing a ready piece stops being copy and pray.
What makes it different · it resolves script and parameter dependencies along the way — which is where manual copying usually breaks.
iFlow agent
An agent that writes Groovy, analyses the iFlow and compares environments in conversation, for when the task does not fit a form.
Gain · covers the irregular request without a new screen for every variation.
What makes it different · it is optional and its cost is declared: you choose when it is worth paying for.
Knowledge base
Answers questions about your own environment, with the context of your tenant.
Gain · the new consultant finds on their own what today costs an interruption of the senior one.
What makes it different · it answers about your tenant, not about SAP's generic documentation.
See it working on your tenant
A guided 14-day evaluation, on your own interfaces — not on a prepared demo.