Xeplr Pro Suite
Xeplr Workflow
A workflow is a sequence of steps. Each step names an Xeplr action, binds its inputs to what earlier steps produced, and routes to the next — branching on conditions, fanning out over lists, and waiting for a person or a job before it carries on.
Partly built. Some of this is working and some of it is not. The limits below are current and specific — read them as part of the description, not as small print.
Processes that live in someone’s head
The export that happens each Monday, the check before an invoice goes out, the chase when a supplier is late. None of it written down, all of it stopping when that person is on leave.
How it works
A step is an action
Each step names an action registered in @xeplr/actions, and its form is drawn from that action’s own input schema rather than a second description of it. Inputs bind to earlier steps’ output, the run’s parameters, or a setting on an allowlist.
Branch, fan out, join
Conditions are compiled with the same expression evaluator the engine runs, so the builder and a run agree on what a condition means. An each transition starts one child run per item, and a join step picks the parent back up once every child has finished.
Wait for a person or a job
A wait step parks the run and issues a single-use resume link, followed from an email or called back by a job. It cannot be claimed until the step is actually waiting, so a mail scanner pre-fetching the link does not move the run on early.
Try a step before you trust it
Try step runs the real action against the sample output of the other steps and shows the input it resolved. It asks first, naming the action, because the action is not reversible.
Chain jobs into a process
A jobs canvas turns jobs into steps that start the job and wait for its callback. A failed job stops the chain rather than letting it run on past a movement that never happened.
Parameters checked before a run exists
A run’s parameters are the union of what every step declares, validated before the run is recorded. Undeclared keys are dropped, and a failure carries the details.
What it does not do yet
Current as of the product readme. If something here matters to you, ask — some of it is next.
- A step’s timeout is saved but not yet enforced by the engine.
- A workflow’s draft status is saved but does not stop it being run.
- Past runs are recorded, but there is no screen for browsing them yet.
- The HTTP routes, running and resuming against a database, and the job step have no automated tests yet.
- Run on its own, the Dashboards and Jobs pages are placeholders — the product ships embedded in Xeplr BI.
See it against your own data
A demo runs on your schema, not a sample dataset. Thirty minutes, no deck.