Reference data and settings lists
How categories, departments, manufacturers, keywords, labor roles, consumables, automation, and logs support daily workflows.
Help updated for v0.10.21 · 2026-07-13
Inventory reference lists
Categories, departments, manufacturers, and keywords are small records that make larger workflows easier to search, group, quote, and report. Categories describe broad families of inventory. Departments help group pick lists and warehouse responsibilities. Manufacturers normalize vendor or brand names so the same company does not appear several different ways. Keywords add flexible search language for how users actually talk about gear.
Create these records before large imports or cleanup projects whenever possible. A messy category or manufacturer list spreads into types, items, reports, labels, and order search. A clean reference list makes search feel smarter because the user can filter by the words the company already uses. Category keywords should also help underlying types be found when those types inherit the category’s language.
Labor, consumables, and order support
Labor roles and consumables support orders without behaving like serialized rental assets. Labor roles describe people or crew roles that may appear on an order. Consumables describe things that may be sold, used, or depleted instead of returned as rental stock. These records help order builders include the real cost and scope of a job without forcing every line item to behave like equipment.
Use these settings when the company repeatedly adds the same non-equipment details to orders. A one-off note can stay on an order, but repeated charges, roles, or stock-like supplies deserve reusable records. That keeps estimates clearer for customers and gives the company better reporting later.
Automation and logs
Automation settings control scheduled or background behavior, while logs explain what happened after those behaviors run. These areas are mostly administrative, but they matter when the app appears to do something without a person clicking a button. A good log should identify the company, actor or service, action, affected record, and outcome in readable language.
Use logs when troubleshooting settings changes, failed saves, background jobs, user access, and support-critical errors. Company-facing logs should stay readable and scoped to tenant activity; platform staff and service-account details belong in admin/support views. When a workflow produces a user-visible failure, the log should help support understand the attempted action without exposing raw internals to the tenant.