Skip to main content

Automation Basics

Automations in OpenDataDSL are event-driven data flows that trigger automatic actions whenever something changes in the platform — such as data being updated, a process completing, or a dataset becoming late.

What are automations?

An automation monitors one or more platform services and listens for specific events. When a matching event occurs, the automation executes a configured action — for example, sending a notification, publishing data to a queue, or triggering a downstream process.

This makes automations the primary mechanism for building reactive, real-time data pipelines without writing polling logic or scheduling workarounds.

Triggering events

Every automation is triggered by an action performed on a specific service. The table below lists all services that support automation triggers and the actions available for each.

ServiceActions
actioncreate, update, delete
aiagentcreate, update, delete
aiassistantcreate, update, delete
aitoolcreate, update, delete
alertraised, closed
alertrecordcreate, update, delete
auditcreate
automationcreate, update, delete
automationlogcreate, update, delete
automationtargetcreate, update, delete
batchcreate, update, delete
calendarcreate, update, delete
curvecreate, update, delete, build, success, warning, failed
dashboardcreate, update, delete
datacreate, update, delete
datasetupdate, late, complete, missing, correction
documentationcreate, update, delete
environmentcreate, update, delete
eventcreate, update, delete
expirycreate, update, delete
extensioncreate, update, delete, install, upgrade, uninstall
extractorcreate, update, delete
groupcreate, update, delete, itemadded, itemremoved, itemupdated
objectcreate, update, delete
policycreate, update, delete
processcreate, update, delete, rollback, tag, untag, rename, run, success, warning, failed
queuecreate, update, delete, message
reportconfigcreate, update, delete
reportcreate, update, delete, run, success, warning, failed
scriptcreate, update, delete, rollback, tag, untag, rename, run, success, warning, failed
scriptlogcreate
secretcreate, update, delete
tenantupdate
transformercreate, update, delete
typecreate, update, delete
unitcreate, update, delete
workflowcreate, update, delete

Anatomy of an automation

An automation is defined as a JSON configuration object. Here is a representative example:

{
"target": "email",
"icon": "bell-fill text-primary",
"enabled": true,
"conditions": [
{
"service": "dataset",
"action": "late",
"id": "MY_PROVIDER.FEED.PRODUCT",
"source": "private"
}
],
"properties": {
"to": "ops-team@example.com",
"subject": "Dataset late: {{id}}"
}
}

Fields

target

The ID of the automation target that will receive and act on the event — for example, email, queue, or process.

icon

The Bootstrap Icons name to use when displaying this automation in the portal. You can also append a Bootstrap colour utility class, e.g. alarm-fill text-success.

enabled

A boolean that controls whether the automation is active. Set to false to pause the automation without deleting it.

conditions

An array of trigger conditions. The automation fires when any condition matches. Each condition has the following fields:

FieldRequiredDescription
serviceThe platform service to monitor, e.g. dataset
actionThe action that triggers the automation, e.g. late
idThe ID of the specific entity to watch
sourceThe data source, e.g. private or public
didAn optional dependent ID — for example, an event that triggers an event curve build

properties

Target-specific configuration used to parameterise the action. The available properties depend on the chosen target — for example, an email target requires to and subject, while a queue target requires a queue name.

template and name

These fields are dynamically generated by the platform based on the entity, action, and target details. You do not need to set them manually.

Next steps