Action Log

The Action Log models all Action submissions as object types to be analyzed and displayed in object-aware Foundry tooling. Use an Action Log object type as an input to decision-making workflows and to monitor changes to your ontology.

Background

Actions are the primary way to modify the Ontology and trigger related side effects. Often, these ontology modifications are the result of a specific decision or are accompanied by data audit requirements. The Action Log simplifies generation and maintenance of object types that represent these decisions and data edits. For easy identification, all Action Log object types are prefaced with [LOG].

Action Log Ontology

Action Log object types map one-to-one with Action types. Submitting an Action generates a single new object of the corresponding Action Log object type. This newly-created object is automatically linked to all objects edited by the submitted Action. By modeling log object types one-to-one with Action types, the Action Log supports capturing context beyond specific object edits, such as which other objects were concurrently edited and the state of the world (as represented by the Ontology) at the time of Action submission.

For example, imagine a Close Alerts Action type that modifies the “Status" property of many selected Alert objects to "Closed". When configured with an Action Log, closing 10 Alert objects at once will yield a single Action Log object with foreign key links to all 10 Alert objects.

Action Log schema

By default, Action Log object types store:

  • Action RID: Unique identifier for a single Action submission
  • Action type RID: Unique identifier for a single Action type
  • Action type version: Version number that auto-increments each time an Action type is updated
  • Timestamp: UTC timestamp of Action submission
  • UserId: Multipass user ID for Action submitting user
  • Edited objects: Primary key values of all objects edited by the Action. Note that storing properties of edited objects other than the primary key is not supported.
  • [Optional] Summary: A customizable string to describe the Action
  • [Optional] Parameter values
  • [Optional] Property values of object reference parameters (this is not supported for object reference parameters if allow multiple values is enabled)

Action Log object types can be configured to store object properties that are not edited by the Action. This allows you to store data edits as well as relevant information about the context of or motivation for the ontology edits.

Returning to the example of a Close Alerts Action type, imagine the Alert objects also have a “Priority” property containing values "High Priority" and "Low Priority" as well as a “Created at” timestamp and a “Source” machine. The Action Log supports storing these properties, even if they are not edited by Close Alerts. By aggregating on "Priority", without editing the column we can answer questions such as “where is the source of most "High Priority" alerts?” or “how long does it take to close "High Priority" alerts?”.

Action Log on Function-backed Action types

To configure the Action Log for a Function-backed Action type, the backing Ontology Edit Function must have Edits provenance configured. See the Functions documentation for more information on Edits provenance.

Action Log timeline

You can view Action Log object types in a timeline using a custom Workshop widget. With this widget, the timeline can be configured to support data audits in order to help answer the questions “what changed, by whom, and when?”

Within Workshop, Action Log object types can be unioned together for a holistic view of edits within a use case or across an ontology.

Configure the Action Log timeline by selecting the edited object type. Then choose which Action Log object types to display, along with the desired Action Log object type properties.