Actions

Actions let you automate routine work across Prizm — escalating a breached SLA, assigning an owner to a newly created asset, recommending glossary terms, or notifying a team — without a person manually watching for each event. Each Action is a rule built from three parts: a trigger (what starts the flow), one or more conditions (what must be true for it to continue), and one or more actions (what happens next). Navigate to Action (or More → Action) to manage them.

​

Rule List

The Action list shows every rule with: Summary cards at the top show counts for All, Active, and Inactive rules, and the scope tabs (Exception, Alert, Asset, Domain, Job, Schedule, SLA, Term) filter the list to rules of that type.

​

The Rule Builder

Opening a rule shows a visual canvas with nodes connected top to bottom, representing the flow in the order it executes. A CANVAS / JSON toggle lets you switch between the visual builder and the underlying JSON definition for the same rule — useful for reviewing or hand-editing the exact configuration.

​

Trigger

The first node defines what starts the flow (for example, SLA Breached). Selecting it shows:

• Target entity — which entity type(s) the trigger applies to, or All target entities
• Conditions — one or more conditions that must all be met for the trigger to fire, added via + Add condition

​

Conditions

Condition nodes (e.g. If matches — “Entity Type equals Issue”) filter which records continue down the flow. Conditions support ELSE IF branches, so a single rule can route different outcomes depending on which condition matches — not just a single linear path.

​

Actions

Action nodes run when the preceding trigger and conditions are satisfied. Examples seen in practice include: Actions can run in sequence (as shown on the canvas) and additional nodes can be appended with the + control at the end of the flow.

​

Generate AI, Validate, and Save

​

Execution

Each rule has an Execution tab listing every run as a Workflow Execution, with: Filters can be saved as a custom view for repeated use.

​

Audit

Each rule also has its own Audit tab — a full, immutable history of changes to the rule itself (not just its executions): every Create and Update event, including which node was added or changed, status transitions (e.g. Pending → Verified), and configuration changes — each entry recording the acting user, timestamp, client IP, and device.

​

Next Steps