Xeplr Pro Suite
X-Flow
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.
Approvals, side by side
An approval step asks roles or people and waits for all, any one, or a number of them, together or in turn, with four eyes and escalation when one is overdue. Each approver finds it under Waiting for you. A step can follow every matching arrow at once, and a meeting point picks the paths back up once enough have arrived, or early when one rejects.
Keep checking a folder or a mailbox
Any step can keep checking instead of running once: a folder, a mailbox, a table. Its own job runs it on a schedule; each time it finds something, the steps after it run for that, in a run of their own, while it goes on checking. A file it has finished with is moved or deleted by a later step, so the next check does not find it again.
Make what a step needs, in the flow
A connection, API or database a step needs and that does not exist yet is made from the step’s own list (＋ New…), with the app’s own form, and picked on save. A screen step designs its form over the flow. Nobody leaves the workflow to set something up and comes back hoping the step still matches.
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.
Started by a schedule, a job, or a person
A workflow’s trigger says what starts it: someone pressing Start, another system, a cron schedule, or a job finishing (successfully, with a failure, or either way). A run gets what fired it, so a step can read the finished job’s status, period and output. A job is also a step: it starts a job and waits for it, and the period flows on to the next.
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 applies to a step that waits; a step that is running is not cut off.
- A draft does not fire on its trigger, but it can still be run by hand.
- A file still in a folder a step keeps checking is found again on the next check, until a later step moves or deletes it.
- The runs a step that keeps checking starts are listed with every other run, not yet grouped under it.
- 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.