Redflow
Menu

Platform

How it works.

Six stages and one record. A producer writes to a stream. A gate decides what needs a person. Only cleared events reach a pull worker inside your network, and an adapter posts them to the system of record, once.

Pipelineone job, end to end
How a Redflow pipeline moves a batchA producer writes to a stream. A gate applies rules; what needs a person goes to a hold until someone decides. Cleared events go to a cleared stream, which a pull worker inside your network reads and hands to an adapter that posts to the system of record. Beside the adapter, a legacy job runs in shadow and the lines are compared.Producerfiles · APIs · formsStreamappend-only · replayableGaterules · thresholds · approverclearedCleared streamonly what was allowedpullPull workerinside your networkAdapterposts once · per-line resultsystem of record: Dynamics GP batchHolduntil a person decidesneedsa personLegacy jobshadow · 0 differcompare lines

  1. Producer

    Whatever creates the work: a file drop from the CIS, an API call from a portal, a form, a nightly export. The producer does not know what happens next. It only writes.

  2. Stream

    An append-only, replayable record of everything received. Nothing is lost between arrival and decision, and any day can be replayed into a shadow run.

  3. Gate

    Rules decide what passes and what needs a person: an amount threshold, a missing cost code, a vendor change. A hold names its approver, and optionally a second one above a higher threshold. The decision, the reason and the time go to the audit log.

  4. Cleared stream

    Only what was allowed. Downstream code never sees a held item, so there is no code path by which an unapproved batch can reach the ERP.

  5. Pull worker

    Runs inside your network and pulls from the cleared stream. Nothing outside opens a connection in. If the worker is down, items wait; they do not disappear.

  6. Adapter

    Posts to the system of record with an idempotency record per batch and a result per line. A retry cannot post twice. For Dynamics GP that means an unposted batch, with the accountant still in charge of posting.

Replacing a job

Shadow, hold, cut over.

Shadow

Watch only

The legacy job keeps posting. Redflow takes the same input, runs the new path to the point of posting, and compares its lines to what the legacy job produced. The diff is on the board every day.

Hold

Gates on, posting on

When the diff has been zero for as long as you want, the gate goes live and Redflow posts. Items the rules do not clear wait for a named person. The legacy job is switched off, not deleted.

Cut over

Per job, reversible

Cut-over is per job, not per system. If something is wrong you turn the old job back on; the idempotency record keeps the swap from posting anything twice.

Monitoring and recovery

  • Lag and backlog alerts per stream, so a stalled job is noticed by the system, not by the accountant.
  • A dead-letter queue with scoped replay: fix the cause, replay the affected items, nothing else.
  • Escalation to Teams or email when a hold or a failure is not acknowledged.
  • An audit trail across all of it: who held, who approved, what posted, what failed.

Deadline-based service-level rules are on the roadmap.

Configured, not coded

A customer's jobs are data: a manifest describes the topology, a rule pack describes the gates, a job template describes the shape, and approver groups and thresholds are settings. Adding the ninth job to a customer who has eight is a configuration review, not a project.

See it on one of your own jobs.

Bring the job you trust least. We will show the gate, the shadow diff and the audit line for it.

Book a demoTalk to us