Appearance
History
Table of Contents
Factorial records changes to manufacturing definitions, inventory, and work orders so that teams can reconstruct how a product was defined, built, and changed over time.
Who did it
When Factorial records who did something, it records how it was done as well: in the app, with an API key, through a plugin, or by Factorial itself. A plugin that runs because Jane completed a task acts for Jane, so its changes are attributed to Jane through that plugin. An organization API key has no person behind it, so its changes are attributed to the key.
Factorial shows the accountable person wherever a record says who did something, such as comments, redlines, holds, reviews and notifications. A small key or plugin icon beside the name marks a change that came through an API key or a plugin rather than the app. Hover over the name to see the full chain: the person, the key, the plugin, and what triggered it.
Work orders, tasks, procedures and projects show who created them and who completed, canceled, released or archived them. Moving a record out of a final state clears that field, for example when a completed task is reopened. For work orders and tasks, the work order's activity feed keeps the earlier change. Projects have no activity feed, so a reopened project no longer shows who completed or canceled it. On work orders, tasks and procedures, the API returns these fields and can filter records by them.
Records created before Factorial started recording this show "Unknown (pre-audit)" for who created them.
Definition history
The Events page records these definition actions:
- Procedure revisions created, submitted or resubmitted for review, returned to draft, released, archived, or deleted, and changes to their owner.
- Procedure approvals, change requests, and review dismissals, including comments attached to those decisions and dismissal reasons.
- Parts created and changes to their part number, revision, description, or base unit.
- EBOM components added or removed and changes to their quantities.
- BOM discrepancies accepted with a reason and the compared EBOM and MBOM quantities.
- Standard fields enabled, archived, or restored for inventory, work orders, or users, alongside field definition and option changes.
- Changes to review policies, including required approvals and the number of days before a review is overdue.
- Units of measure and unit families created or deleted, and units renamed. Creation and deletion records preserve the configured conversions.
Open an event to see its actor, changed values, and connected records. A procedure event links to its revision diff. View history on a connected procedure family shows events across its revisions; a revision has its own history too. Event snapshots preserve names and values after the definition is renamed or deleted. Definition events are recorded from the introduction of this history onward; earlier actions are not backfilled.
One EBOM operation records one event per changed parent part, with component changes in its details. Creating a procedure revision records one event for the revision. Step edits, document edits, requiredness changes, dependencies, and procedure part requirements remain in revision diffs. Comment-only reviews remain in the review discussion. Saving an unchanged value does not add a change event.
These definition history events do not trigger plugin hooks.
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.
Issue history
Issues record their creation, changes to their title, description, owner, kind, and status, affected records linked, unlinked, and split, and holds placed and released. Each event links to the issue and to the affected task, work order, or inventory line, so the same event appears in the history of each of them. The issue page shows these events together with the activity on its affected records.
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:
- Redlines opened, reviewed, applied, rejected, or canceled, and the holds they place and release.
- Issues raised from or linked to the work order or its tasks, and holds placed and released by issues.
- 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.
- Work order creation and instantiation, and work order and 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 report is planned.
The execution timeline draws the same status history as bars over time and measures the work order's lead time, processing time, and hands-on time.
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.