Triggers & Invocation

In Dimension, Actions don’t have standalone schedules or external event listeners. They’re invoked by Studio apps — when a user clicks something, submits a form, or the app’s logic decides it’s time. That’s a deliberate design choice: it keeps every Action’s invocation auditable in the context of a real app, with a known user and a known reason.

The three invocation patterns

Button click
Form submission
Conditional / scheduled

The most common pattern. Drop a button into a Studio app, wire it to an Action, and any user with access to the app can fire it on demand.Composer prompt example:

"Add an 'Open Ticket' button on each row of the table.
 When clicked, invoke the Jira Webhook Action with
 the device name and the failing control as the
 payload."

Forms inside an app collect input, validate it, and post the payload to an Action.Composer prompt example:

"Add a form with fields: device name, severity, description.
 On submit, invoke the ServiceNow Webhook Action with the
 form data plus the current user's email."

For “run this on a schedule” semantics, build a Studio app with auto-refresh that invokes the Action whenever a condition fires.Composer prompt example:

"On every refresh, if there are devices with critical risk
 that haven't been alerted in the last 4 hours, invoke the
 Slack Webhook Action with the list."

The app itself manages cadence — Actions stay stateless.

Payload patterns

Actions receive a payload from the app. Common payload shapes:

Device events — device name, owner, risk level, failing control
User events — user email, manager, last login, MFA state
Form data — exactly what the user entered, plus context (user, app, timestamp)
Aggregates — counts and lists, e.g. “10 devices failed Cyber Essentials this week”

Composer infers the right payload shape from your prompt. To override, name the fields explicitly:

"Invoke the Slack Action with this payload:
 - channel: '#sec-ops'
 - text: 'New critical device: {device.name}'
 - blocks: [...]"

Variables in Action payloads

Action payloads can reference data from the row, the current user, the timestamp, the app itself, and any other context Composer has wired into the surrounding app. The exact field names available depend on the Data Feeds you’ve connected and the inputs you’ve defined on the Action — ask Composer what’s in scope when it wires up the invocation.

Best practices

Start with notifications, not remediation

Configure an Action to notify before you let it change things. Notify Slack about device isolations before you let an app actually isolate the device.

Make the user explicit

Actions that change state should be invoked from a button or form, not a background condition. The user click is your audit trail.

Use confirmation steps for high-risk Actions

For destructive Actions, prompt Studio to add a confirmation dialog before the button invokes the Action. “Are you sure? This will isolate 12 devices.”

Test against a sandbox endpoint first

Webhook Actions are easy to test against requestbin.com or your own staging endpoint before pointing at production Slack / Jira.

Actions Overview

What Actions are, and the Composer-based creation flow

Integrations

Webhook and Email patterns for common services

Get started

Core Concepts

Build

Reference

Settings

Trust & Security