Qyrus Test Orchestration

A checkout does not care that login is a Web script, payment is an API call, and verification happens on a phone. Testers did, because each surface lived in its own repository, run, and report, and somebody in the middle had to hold the whole flow in their head.

So the product object became the workflow itself: something teams can find, compose, run, and return to. The projects view already shows All Projects (38, as shown), which is why search, sort, owners, counts, and recency stay visible instead of hiding in a second screen.

The earliest exploration proved the premise and exposed the problem. Nodes sat on one left-to-right band and published their variables as a flat wall of chips grouped by source script. You could connect two nodes, but you could not say which value went where.

The line meant "after", not "carries". The condition icon had the same flaw in miniature: two labelled exits, nowhere to show which value the rule read, and no structure for a third branch. Comparing this trial with the shipped model narrowed the redesign to one job: make data contracts visible, not just sequence.

The wireframe pass took the trial's flat condition icon and gave its exits names — Show superadmin and Show error — so a branch finally read as a rule, not just a fork. A Results tab paired a live workflow diagram with a step-by-step log, and a Results table held every run across every workflow in one list.

It was still one script on one canvas, not yet the multi-script model that shipped — but the branch, the live run view, and the results table all carried forward into the final design.

The canvas opens beside the script library, not a blank palette. Pick a service, walk the same repository your team already uses, and drag a script into the flow. Nothing gets rewritten to become part of a journey.

Because most enterprise tools are empty on day one, the empty states do instructional work. Projects tells you how to begin, Workflows routes you back to where creation actually happens, and Reports admits that evidence does not exist until a run does.

Redrawn, a node stops being a black box without becoming a data dump. It shows the steps it will run in script order and the outputs it produces, each on its own port, so a connection can mean one specific hand-off instead of a vague dependency.

That only works if incoming data can land precisely. Web actions, API requests, and mobile loops all use the same input-dialog structure — search, filters, mapped-only toggle, warning, and Save — while each service keeps the vocabulary of its own data model.

Real journeys fork, wait, retry, stop, and notify. The moment those actions require code, the person who owns the workflow stops being the person who can change it.

The expression builder opens on values the run already knows — upstream node outputs and Data Hub columns — then adds operators, functions, and keywords from adjacent tabs. Utilities stay visually distinct as circles with stable colours, while Alert separates composing the message from deciding whether Slack or Teams should fire.

Enterprise orchestration fails if the canvas and runtime disagree. Environment settings therefore work at two altitudes: one workflow context for everything, or per-script environment and database settings listed in execution order, with the same node numbers the canvas uses.

That structure holds when the flow spans services: a Web script publishes product_price, a Branch Hub decides what happens next, an API verifies the order, mobile checks the result, and the same flow can then be scheduled to run unattended. A recurring run is an auditable commitment, so cadence, next run, progress, and owner stay on the row.

Reporting is one system at four depths: portfolio, run list, the run, and the failing step. The dashboard shows pass and fail, service usage, and where execution time goes; the list keeps five real statuses distinct instead of flattening everything into green or red.

The reports views show 2,952 executions (as shown), so search and filters are structural, not decorative. Open a failure and the report answers where before why: first the step that failed in sequence, then expected versus actual values, loop index, printed branch rule, API assertions, headers, and response.

What this evidence set covers is the complete loop, and it closes where it opened. The problem was that a red step told you something broke but not what it broke after. By the end of this set, a failed run names the step, the rule it evaluated, the value it expected, and the value it got — each traceable back to a node on the canvas.

What it does not cover is what happened next. These are shipped screens, not a release record. I can show that the model is coherent and that a tester can follow it end to end; I cannot yet show that it saved anyone time, and I would rather say that than decorate the work with numbers I did not measure.