User Actions
This is the catalog of every action a user can take in the platform today — both writes (create, update, delete) and reads (lists, lookups, detail views). It's the source of truth that everything downstream in the design phase builds on:
- Layer 1 (Data) confirms each action has the data it needs.
- Layer 2 (Domain Components) defines the component APIs that back these actions.
- Layer 3 (Business Logic) defines the workflows that compose them.
- Layer 4 (API) defines the public endpoints that expose them.
It is pre-API — actions are described from the user's perspective, not as endpoint signatures. Endpoint design happens in Task 6.
How it's organized
One page per domain. Inside each page, two sections: Writes (commands) and Reads (queries).
| Page | Covers |
|---|---|
| Platform | Auth, organizations, users, invitations, Home dashboard, account, preferences |
| Purchase Orders | POs, items, receipts, PO status types |
| Work Orders | WOs, items, receipts, WO status types |
| Sales Orders | SOs, items, timeline notes, documents, order channels, order status types, fulfillment status types |
| Materials Inventory | Materials inventory ledger, summary, transfers |
| Finished Goods Inventory | FG inventory ledger, summary, transfers |
| Customers | Customers, customer types, segments, brokers |
| Products | SKUs, SKU types |
| Bill of Materials | BOMs (recipes linking inputs to output SKUs) |
| Vendors | Vendors |
| Materials | Materials, material types |
| Locations | Fulfillment locations (used as ship-to, work site, stock location) |
| Contacts | Shared contacts pool (people linked to customers, vendors, and other entities) |
Action format
Each action has:
- Name — verb + noun (e.g., "Create purchase order").
- Trigger — where in the frontend the user initiates it today (page or component).
- Description — one sentence on what it does, business-side.
Anything beyond that (inputs, validation rules, outputs) is captured later in component/workflow/API design.