Finance & operations
Every supplier needs a decision. And someone to own it.
It started with…
Finance has the spend figures. But reviewing each supplier means finding an owner, understanding the contract and agreeing on what to keep, challenge or cancel.
So we built…
A shared review workspace. Each owner sees the suppliers to review, records a decision and explains it. Finance can follow the campaign and explore the spend behind it.
Take a look inside
Screen 1 of 6Decision queue
One workflow connects owner, decision and justification.
What we set out to change
Help the team prioritise its review and follow decisions through, keeping potential savings separate from changes actually implemented.
How it is builtData model, code, controls and team ownership
The user journey
- 01
Assign an owner and inspect the supplier’s history.
- 02
Draft the decision, contract details and justification together.
- 03
Validate the row, then follow campaign progress and unresolved items.
Base structure
| Entity / table | Key fields | Relationships |
|---|---|---|
| Suppliers | Owner · decision · contract · expiry · justification | One supplier → many accounting entries |
| Accounting entries | Amount · date · account · analytical code | Each entry links back to its supplier and accounting references |
| Accounting references | Accounts · analytical codes · sites · activities | Shared dimensions support the spending breakdown |
| Access rules | Member · group | Business editing rules complement Airtable permissions |
Technical implementation
- The review queue reads supplier records. The heavier accounting dataset is mounted only when the analysis needs it.
- A local draft is shared by the row and the detail panel; validation sends its changes together.
- Pure business functions cover completion rules, savings logic, grouping and reconciliation. Status colours come from Airtable field options.
Engineering decision
Serialise writes and surface conflicting edits
Adapted from the review’s shared write queue. Autosave and bulk edits use the same sequential queue. Observed field values are compared before enqueueing; a conflict returns to the user. This is a local conflict check, not an atomic lock across Airtable sessions: another write can still occur after the comparison. SDK permissions remain authoritative.
// Adapted core: one queue per mounted review workspace.export function createWriteQueue(table) { let tail = Promise.resolve(); return function enqueue(record, fields, expected = {}) { const permission = table.checkPermissionsForUpdateRecords(); if (!permission.hasPermission) { return Promise.resolve({ status: "denied" }); } const conflictingFields = Object.keys(expected).filter(id => { const field = table.getFieldByIdIfExists(id); return field && record.getCellValueAsString(field) !== expected[id]; }); if (conflictingFields.length) { return Promise.resolve({ status: "conflict", recordId: record.id, conflictingFields, attempted: fields, }); } // Both autosave and bulk-edit callers await this same queue. const job = tail.then(async () => { await table.updateRecordsAsync([{ id: record.id, fields }]); return { status: "saved", recordId: record.id }; }); // Recover the queue, while preserving rejection for this caller. tail = job.catch(() => undefined); return job; };}Adapted implementation excerpt
Controls and boundaries
- Editing controls consult Airtable permissions; business assignment rules are an additional layer, not record-level security.
- AI supplier descriptions are optional hypotheses read from an Airtable field. A person still makes the purchasing decision.
- Completion and savings use explicit business definitions: a potential saving is not treated as an implemented decision.
Who can contribute
- Operations: maintain owners, decisions and justifications in the interface.
- Builders: maintain statuses, fields and reference tables in Airtable.
- Developers, with Claude if useful: evolve the tested rules and release a versioned extension.
What supports this case
The live interface exposes entry, progress, spending and quality views; the repository contains the corresponding business logic and release checks.