Checking your InspectAssets session…

INSPECT ASSETS MANAGEMENT PORTAL Product Guide
Signed in
Open app

Controlled automation

Operational Playbooks

Review or configure event-driven operational responses and follow their execution history. Playbook access is separate from permission to open Organization Settings.

View: view_playbooks or manage_playbooks. Changes and retries: manage_playbooks.

Open and review a playbook

  1. Open Operational Playbooks from the web tenant menu. Tenant administrators can also open the panel through Organization Settings → Playbooks.
  2. Confirm the tenant, playbook name, trigger, conditions, actions and enabled state.
  3. Read Execution history to see recorded runs, status, action results, attempts and failures. View access does not grant creation, editing, enable/disable or retry authority.

Create a controlled response

  1. With manage_playbooks, complete Create playbook with a name and a supported trigger.
  2. Add conditions where needed. All configured conditions must match; leaving them empty applies to every matching trigger.
  3. Add supported actions and select the required recipients, owner or asset context. Targets must belong to the active tenant.
  4. Review the configuration before enabling it, then select Create playbook. Use Update playbook when editing an existing configuration.
  5. Confirm it appears with the expected enabled state and inspect the execution history when a relevant real event occurs.

Supported triggers and actions

Triggers cover supported inspection completion/approval, limitation creation/overdue/resolution, corrective-action creation/completion/verification and condition-event opening/resolution. The UI lists the current supported contracts.

Actions can notify users, assign supported work, escalate management attention, create a follow-up inspection, create a work order or request corrective-action verification. Each action depends on the event's available context: a work order or follow-up inspection needs an asset; verification requests need eligible completed corrective work.

Investigate and retry failures

Read the failure and action results in Execution history. Correct the underlying configuration or operational issue first. Users with manage_playbooks can select Retry on a failed execution. The system records the playbook snapshot/version and uses idempotency boundaries for replayed triggers and actions; review the resulting records rather than assuming every retry succeeded.

Automation follows recorded facts

Playbooks apply configured conditions to factual lifecycle events. They do not run arbitrary code or infer failure propagation, probability or causal impact. Permission and tenant checks still apply to the actions they perform.

Playbooks is currently a web workflow. No dedicated screenshot or tutorial is included for this new chapter; its instructions were checked against the local source on 2 October 2026.

Source reviewed 2026-10-02 Manual v2.0.19