Every iFlow makes the next one better.

iFlow flywheel – Every iFlow makes the next one better – because the rules, snippets, tests and docs from this round are already there in the next.

1. Build (XML Workshop · Snippets, Community, in the product): You build in the SAP editor as usual. Right next to it: XSD editor, XSLT mapping as a diagram, XPath by click and Groovy snippets – no second tab. In the next round: What you saved as a snippet or sample last round is now a template. With Pro, Ask Tailor drafts the next iFlow from your requirements.
2. Review (Quick Review, Community, in the product): One click: health score from 0 to 100, findings by severity with reason, location and fix. Clicking a finding jumps to the step in the editor. In the next round: Accepted risks are listed with their justification, and the team rules are checked too. Today’s score is the bar for tomorrow.
3. Test (Test Studio · Groovy Runner, Community, in the product): REST, OData and SOAP with environments and assertions, through the Cloud Connector if you need it. With Pro, the Groovy script runs in the Runner against a sample payload, without a deploy. In the next round: Collections and test suites from the last round run again before and after the deploy.
4. Compare (Version Diff · Tenant Compare, Pro, in the product): Before the transport: version against version, DEV against PRD. The changelog suggestion lands in SAP’s “Save as Version” dialog. In the next round: The version history shows what is new since your last visit – and who changed it.
5. Operate (Monitor · Error analysis, Community, in the product): Failed messages grouped by cause instead of one by one, with a suggested fix. Plus deployments with drift and certificates with their expiry dates. In the next round: The cause is known, and so is the fix. With Pro, Trace Explorer and Message Journey follow the message across several iFlows.
6. Understand (Forecast · Heatmap, Pro, in the product): When does the load arrive, which step is the slowest, which iFlow has been changed but not deployed? In the next round: More history, a more accurate forecast – the view measures its own accuracy and shows it.
7. Document (Documentation generator, Pro, in the product): Interface documentation from the tenant as Markdown, PDF or straight into Confluence. In the next round: The docs are accurate because they come from the tenant. Whoever builds the next iFlow starts with them – back to station 1.

Operations flywheel – Every error makes the next one less likely – because the cause becomes a rule that checks before the deploy.

1. Error (Message Monitor, Community, in the product): A message fails. The monitor shows it, filtered by iFlow, status, time range, correlation ID and application ID. In the next round: With Pro, the forecast shows the error rate next to the previous period – you can see whether the fix worked.
2. Cause (Error analysis, Community, in the product): Hundreds of messages, one cause: error analysis groups them by error signature and suggests a fix from the knowledge base. In the next round: It recognises the same signature straight away – with last time’s fix.
3. Explain (Ask Tailor, Pro, in the product): Ask Tailor explains the error in plain language, looks for the cause of a run and predicts the path of a sample payload through the iFlow – masked, with your model. In the next round: Known error patterns point to the matching book by our authors.
4. Fix (Groovy Runner · Test Studio, Pro, in the product): Check the fix in the Runner against the real CPI runtime, with trace data as the sample. Then send the request again in Test Studio. In the next round: The sample from the failing case stays saved and runs again with the next fix.
5. Rule (Quick Review · custom rules, Community, in the product): The 40 Quick Review rules check error handling, retries, timeouts and logging before the deploy. In a team, your own rules are added. In the next round: What went wrong once is now checked in every iFlow – including those of new colleagues.
6. Prevent (Certificates · Forecast, Community, in the product): Expiring certificates with calendar export, deployments with drift. With Pro: load peaks for the coming days and hours. In the next round: The next incident shows up in advance, before it lands in the monitor – back to station 1, just less often.

Team flywheel – Every person on the team makes the tenant better – because standards, rules and metrics reach everyone, not just the people who already know them.

1. Install (Community, Community, in the product): One person installs the extension, with no account and no licence key. It uses the existing SAP session. In the next round: The next person gets extension, licence and policy through the IT department’s browser policy.
2. Share (Review report · Docs, Community, in the product): The review report goes into the pull request or ticket as Markdown; with Pro, the docs go to Confluence. In the next round: Reviews look the same for everyone – you compare scores, not opinions.
3. Define (Policy Studio, Team, in the product): Naming standard, rules, blocked write actions and allowed AI endpoints as one team policy – put together and tested in Policy Studio. In the next round: Custom review rules grow with every finding. The policy can carry an expiry date and is then renewed deliberately.
4. Roll out (Browser policy, Enterprise, in the product): IT rolls out extension, licence and policy via Intune, GPO or Google Admin. Users cannot change the policy. In the next round: New team members have the same rules as everyone else on day one.
5. Measure (Tenant Health · Risk Radar, Team, in the product): Tenant metrics and trend, plus the security posture in eight dimensions with drill-down to the exact location. In the next round: The history shows whether the standards are working – as a number for management, not a feeling.
6. Clean up (Landscape & Cleanup, Team, in the product): A system map of the tenant and candidates for cleanup: no messages, never deployed, empty packages, unused script collections – each with a reason, never deleted automatically. In the next round: Less legacy, a faster index, a clearer map – the next team member finds their way around sooner. Back to station 1.

Learning flywheel – Every iFlow makes you better – because the Coach remembers where you are and the next round starts right there.

1. Plan (Implementation Coach, Coach, in the product): You describe the scenario in two sentences. The Coach lays out a build plan – sender, validation, mapping, error handling, restart, monitoring, docs – each step with the why and typical mistakes. In the next round: The build plan starts with the topics you left open last time. With Ask Tailor, it is tailored to your scenario.
2. Build (Live check, Coach, in the product): You build in the SAP editor. The Coach checks the open iFlow against the plan: done, open, problematic – the next step is at the top. In the next round: What you learned last round is already done this time, before the Coach asks.
3. Review (Quick Review, Community, in the product): Health score, findings with reason and fix. For beginners, what counts is not the number but the why behind each finding. In the next round: Today’s score sits in the learning path next to last week’s.
4. Restart (Restart guide, Coach, in the product): Can the iFlow safely run again after an error? A verdict with a score, a numbered build plan that jumps into the editor, and a flow diagram. In the next round: Idempotency, a dead-letter queue and an Exception Subprocess are in the next iFlow from the start.
5. Version (Versioning advisor, Coach, in the product): Is a new version worth it now? A comparison with the last one, a suggestion of major, minor or patch with reasoning and a changelog. In the next round: The version history reads like a logbook – also for the colleague who takes over the iFlow next year.
6. Learn (Learning path · Flashcards, Coach, in the product): Your most frequent gaps, the trend of your scores and short lessons with examples. Only rule IDs, topics and scores are stored – locally. In the next round: The learning path moves the next gap to the front. Back to station 1, with one topic fewer.

Debug flywheel – Every error you have found once becomes a test – and the next fix is checked against all previous runs.

1. See (Inline debugger, Pro, in the works): The run sits on the diagram: green, red, grey, the router branch taken, the duration at every step. A click shows body, headers and properties before and after. In the next round: The live bar shows new errors as soon as they happen – you open the run before anyone calls.
2. Compare (Good vs. bad, Pro, in the works): The failed run next to a successful one: the first difference with its reason – another router branch, a missing header, another format. In the next round: Watched values are already set up: the column shows at once where the field becomes empty.
3. Cause (Root cause search, Pro, in the works): Candidates with evidence: “errors since version 1.4.2 was deployed at 14:02”, the same error in three other iFlows, certificate expired. In the next round: The incident report is already there: timeline, impact, cause – as Markdown or for Jira.
4. Fix (Checked fix, Pro, in the works): Ask Tailor suggests a minimal change. iFlowTailor checks it on a copy with Groovy Lint, review rules and the simulator before you see it. In the next round: The check runs against all the regression tests earlier rounds have left behind.
5. Test (Trace as regression test, Pro, in the works): The run that failed becomes a test with one click – masked, local only. The simulator plays it through without deploying. In the next round: Path coverage shows which branches have never run – that is where the next test is missing.
6. Gate (Test gate, Pro, in the works): Score, the latest suite run and critical findings sit on the Deploy button. On request the gate asks before deploying. In the next round: Every test from a real run makes the gate more precise. Back to station 1, with one error fewer.