By connecting a process to a datasource, you can bridge the gap between an abstract process definition and real-world observations. This data can be used to conduct initial process mining or to monitor performance and find bottlenecks.
Machinery connects to two types of object data in the ontology: process objects and log objects. The side panel for data configuration is accessible through the main toolbox or from process containers.
A process object is an entity that goes through a process.
For example, this may be an Employee
for an onboarding process, or an Invoice
for a purchase-to-pay process. The state of the entity is explicitly tracked by a string property, typically called state
. The values of the state
property (for instance, "created" or "approved") are represented by state nodes on the graph.
A state value may have dependencies, like submission criteria in actions or automations that are triggered by a certain state condition. Changing the state value in Machinery does not update these dependencies, nor does it change the values in the ontology data.
In the multi-process setting, each process container captures exactly one state property on an object type.
As in the resource example screenshot above, an object type can have multiple state properties; for instance, a coarse state and a granular state.
The process object type represents the latest state of the entity, and therefore cannot inform on state transitions and temporal patterns.
A log object represents an individual change to an entity’s state. Log objects contain a reference to the process entity, its previous state, its new state, and the timing of the transitions.
NULL
for external changes.NULL
for external changes.Maintaining such a log requires orchestration when edits are made. Machinery provides a standard solution that can be installed from within the application. Setting up a log object type requires a process object type.
A dialog will guide you through the setup. You can choose which source of edits you want to track:
Tracking logs from platform edits for object types with multiple datasources or row-level permissions is currently not supported.
If you want to track changes from external datasources, you must select a dataset in standard changelog format, which is a simpler version of Machinery’s log object type schema. That dataset is typically upstream of the object type datasource, and contains the following columns:
True
, that object will not appear in the ontology.On confirmation, Machinery will install a Marketplace product into a folder of your choosing. This product contains a Pipeline Builder pipeline that computes log entries from the configured sources into the correct format. The product also deploys the log object type itself with an ontology link to your process object type.
After the installation is complete, the pipeline needs to complete an initial build, and the log object type needs to be indexed in the databases before the data is available for mining and monitoring.
The deployed pipeline is scheduled to run on every change to any of its datasources. As a result, the log object type lags behind the process object type by one build and one indexing job, typically about 2-5 minutes. If you require real-time updates, you need to maintain a custom log object type.
You can manually map a custom log object type if it fulfills the minimal schema.