Skip to main content
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

Action page showing All, Active and Inactive cards and a table of rules

The Action list with summary cards, scope tabs and one row per rule

The Action list shows every rule with: Summary cards at the top show counts for All, Active, and Inactive rules, and the scope tabs under the table title (for example Domain (1) and Exception (4), each with a count) filter the list to rules of that type. Use the pencil icon on a row to open the rule and the trash icon to delete it.

The Rule Builder

Opening a rule shows the rule’s name and status (for example Verified), with Overview, Execution, and Audit tabs beneath it. The Overview tab holds 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.
Action rule canvas showing an Exception Created trigger, Assign Owner and Send Notification nodes and a trigger settings panel

The rule canvas: a trigger node with its condition, followed by action nodes, and the settings panel for the selected node

Trigger

The first node defines what starts the flow (for example, Exception Created or 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: The filter, sort, and search icons above the table narrow the list of runs.
Execution tab showing workflow executions with status, start time, duration, actor and end time

The Execution tab listing workflow runs for a rule

Audit

Audit log table for an Action rule

The Audit tab of a rule: every create and update, with the acting user, client IP and device

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

Exceptions

Actions frequently target exception records — see how exceptions are structured.

Alerts

A common trigger source for Actions.