Appearance
History
Table of Contents
Factorial records changes to inventory and work orders so that teams can reconstruct how a product was built and how its execution changed over time.
Inventory history
Inventory history records the operations that affect an inventory line. Operations include creation, movement, installation, consumption, splitting, merging, and scrapping. It connects those operations to the relevant work orders, tasks, people, equipment, locations, and timestamps.
See Inventory history for details.
Work order history
Each work order has an activity feed that records management and execution events. The feed provides a chronological record of what changed, when it changed, and who performed the action.
Recorded events include:
- Redline creation, review, and submission.
- Issue creation and association.
- Changes to ownership, scheduling, location, and other work order details.
- Task check-ins and checkouts.
- Data-input entries and edits.
- Material actions performed during execution.
- Task status changes.
The activity feed appears below the main content on the work order page. Filter it by person or time range to isolate the events relevant to an investigation. A printable PDF report is also available.
Labor hour history
The labor hour activity shown for a task is a filtered view of the work order's complete activity feed. It focuses on check-in sessions and later corrections to those sessions, including the person who made each change and the recorded reason.
This shared history keeps labor corrections connected to the rest of the work order execution record.
Custom events
Custom events track custom metadata and can be queried to create reports or dashboards. A custom event has a name, timestamp, and payload. The payload needs to be preconfigured to be a specific set of fields. Custom events can then be triggered via the API for manual slash commands. For example, to generate a report of how long perishable items have been outside of a freezer, there could be two custom events, one for entering a freezer, and one for exiting. Each custom event would have an inventory field, and the default timestamp. Before exiting the freezer, the event could be invoked with /freezer-exit, and a pop up with the inventory field would appear. The inventory could be scanned, and the event logged. In a dashboard, these events could be queried to generate a report showing the time each inventory item has spent outside of a freezer. Alternatively, an integration could be setup with RFID chips on the items so that as items leave the freezer area, an API call is made to log the freezer exit and freezer enter events.