> ## Documentation Index > Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt > Use this file to discover all available pages before exploring further. # Actions > Configurable trigger → condition → action workflows that automate business processes across the Prizm platform. 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: | Column | Description | | :--------------------------- | :-------------------------------------------------------------------------------------------------------- | | **Name** | The rule's name | | **Scope** | The entity type this rule operates on — e.g. Exception, Alert, Asset, Domain, Job, Schedule, SLA, or Term | | **Triggered** | Number of times the rule has fired | | **Created** / **Created By** | When the rule was created and by whom | | **Active** | Toggle to enable or disable the rule without deleting it | 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: | Action | What it configures | | :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Assign Owner** | An **Assignment mode** (e.g. Reassign owner) plus owners to assign per role — **Business**, **Technical**, and **Steward** — each addable independently | | **Send Notification** | Notification delivery for the matched record(s) | 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 | Control | What it does | | :-------------- | :--------------------------------------------------------------------------------------------------------------- | | **Generate AI** | Generates a starting rule from a natural-language prompt, which you can then refine on the canvas or in JSON | | **Validate** | Checks the rule for configuration errors before saving | | **Save** | Saves the rule. New rules start in a **Pending** state and move to **Verified** once reviewed/saved successfully | ## Execution Each rule has an **Execution** tab listing every run as a **Workflow Execution**, with: | Column | Description | | :------------------------------------------------- | :------------------------------------------------------------------ | | **Execution ID** | Unique identifier for the run | | **Status** | Completed, Running, or Failed — also available as quick filter tabs | | **Start Time** / **End Time** / **Total Duration** | Timing for the run | | **Actor** | The identity the rule executed as | | **Action Name** | Which action(s) ran | | **Nodes** | The nodes touched during execution | 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 Actions frequently target exception records — see how exceptions are structured. A common trigger source for Actions.