Introduction

Scenario: Analysts must assign owners, escalate severe disruptions, and track mitigation status from the command center.

Day 6 turns your disruption-response ontology from something analysts read into something they can act on. In Foundry, an action type defines a set of changes or edits to objects, property values, and links that a user can take at once, committing those edits to the Ontology as a single transaction. This is how the command center captures human decisions, such as who owns a disruption and how severe it is, directly into the data so every connected application reflects the change instantly.

For the supply-chain problem, this matters because severe disruptions cannot sit unowned in a dashboard. Action types let you embed your operational logic, assigning an owner, escalating a severe event, and marking a disruption resolved, so analysts manage the response while thinking about objectives rather than hand-editing individual properties. Each action carries parameters that standardize the inputs (an owner to pick, a status to set) and rules that determine exactly which properties and links change.

By the end of the day you will have action types wired with required fields, submission criteria that gate when an action can run, and side-effect rules like notifications that alert stakeholders when escalation happens. You will exercise these from a Workshop command center, where button groups expose actions, parameters pre-fill from the selected disruption, and a green success toast confirms the writeback. You will validate both the happy path and the exception path so analysts trust the workflow under pressure.

Capability focus: Ontology Actions (rules, parameters, submission criteria), Button Group · Artifact: Triage and escalation workflow

Key concepts

Companion video

1. 1

   Define action outcomes and required fields

   Start by deciding what each action should change in the Ontology, because an action type bundles edits to property values and links into one transaction. In Ontology Manager, create a new action type, set Change object(s) to Modify on your Disruption object, and add the properties the action touches (owner, status, severity). Then open the Forms tab to shape the auto-generated parameters into required fields, switching free input to Multiple choice where you want analysts to pick from a controlled set like a defined list of statuses.

   not startedself-attested

   Mark complete

   Self-attested: each action has clear intent and required fields.

2. 2

   Add the assign / escalate / resolve action types

   Build three action types so the command center can drive a disruption through its lifecycle, each using an Ontology rule that maps parameters to property edits: Assign sets the owner property, Escalate raises the severity and status, and Resolve sets status to resolved. On Escalate, attach a side-effect notification rule so it sends a stakeholder alert after the edit applies, using the action parameters to customize recipients and content. Remember a single function rule could do all the logic, but when present no other rule may be configured, so keep these as simple modify rules unless you need custom code.

   not startedinstance check

   Run check

   Confirms the three Ontology Action types exist.

3. 3

   Apply triage: assign an owner to a disruption

   Now run the workflow from the command center, where actions are exposed through a Workshop button group and the Disruption parameter pre-fills from the disruption selected in your table. Click the Assign button, choose the owner in the actions form, and submit; on success you will see a green toast confirming the writeback and the owner property updating across every connected view. Add a submission criterion in the Security and Submission Criteria tab so escalation only applies to qualifying objects, for example restricting Escalate to disruptions already flagged severe.

   not startedinstance check

   Run check

   Confirms an action was actually applied — a DisruptionEvent now has an owner and a triaged status.

4. 4

   Test happy-path and exception-path scenarios

   Validate the workflow both ways so analysts trust it during a real disruption. For the happy path, select an unowned severe disruption, run Assign then Escalate, and confirm the property edits commit, the notification fires, and the status reflects everywhere. For the exception path, attempt Escalate on a low-severity disruption and confirm the submission criterion blocks it (the form should flag the issue rather than apply the change), proving that rules and conditions prevent invalid operations.

   not startedself-attested

   Mark complete

   Self-attested: exception handling is documented.