# 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](https://assemblyline.sh):

- 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](https://finopsbricks.com): Statements, Transactions and the Ledger are separate systems, each with its own app and API.

## Why parts

| | One internal-tools platform | Internal Ops |
| --- | --- | --- |
| Where the workflow logic lives | In the platform's builder | In code, in your team's Git repo |
| Where the work runs | Wherever the platform runs it | On a worker you run, next to your data |
| What happened on a given run | Whatever the platform logs | A work record for every run, with each step's output |
| Work that fails | Whatever the platform does with it | Kept in a failed bin with its error until fixed |
| Changing one part | On the platform's terms | Replace one workflow or one system on its own |

## Next

- [Example workflows](/docs/example-workflows)
- [Assembly Line concepts](https://assemblyline.sh/docs/concepts), for the full detail