Internal Ops

Workflows and systems of record

Workflows

A workflow is work that moves: an invoice arriving, a document being filed, a record copied from one system to another. In Internal Ops each workflow runs as an assembly line on Assembly Line:

  • A line is one workflow. It's a sequence of stations.
  • Each station runs a few steps. A step is a function your team writes in Node.js, kept in your own Git repo.
  • Steps run on a worker your team runs, on your machine or server, so your data and credentials for other systems stay there.
  • The Orchestrator schedules each station run and records it as a work record, with each step's output.
  • Work moves between stations as workpieces through input, doing and output bins. Work that fails lands in a failed bin with its error, and stays there until someone fixes it.

Systems of record

A system of record is data that stays: the bank statements, the transactions, the ledger. In Internal Ops each one holds one kind of data, in its own app, with its own API. Workflows read from them and write to them.

Finance is already built this way in FinOpsBricks: Statements, Transactions and the Ledger are separate systems, each with its own app and API.

Why parts

One internal-tools platformInternal Ops
Where the workflow logic livesIn the platform's builderIn code, in your team's Git repo
Where the work runsWherever the platform runs itOn a worker you run, next to your data
What happened on a given runWhatever the platform logsA work record for every run, with each step's output
Work that failsWhatever the platform does with itKept in a failed bin with its error until fixed
Changing one partOn the platform's termsReplace one workflow or one system on its own

Next