Automation rules in Dawiso are defined using JSON, a lightweight and readable format commonly used for configuration. JSON makes it easy to structure automation rules in a clear and consistent way, while also allowing advanced customization.
If you are already familiar with the structure of automation rules, you can skip to the examples!
- Example: Deadline Notification
- Example: All Attributes Completed
- Example: Setting Attribute
You can write or edit your automation rules in any text editor that supports JSON, such as Visual Studio Code, or directly in the Dawiso built-in editor (Settings > Automations > Rules > + New rule).
To enable helpful features like tooltips, auto-completion, and validation while editing, make sure to include the schema at the top of your JSON file before specifying the rule’s trigger, filtering stream, and the action to be performed.
Here’s a basic template of an automation rule:
{
"schema": "https://schema.dawiso.com/automation-schema.json",
"automations": [
{
"key": "",
"name": "",
"triggers": [],
"stream": [],
"actions": [],
}
]
}Let’s break down the key components of an automation rule. Each rule contains:
| Property | Description |
|---|---|
key | Unique key of the automation rule. |
name | Name of the rule that will be used in the list of all automation rules. |
triggers | Definition of the events that activate an automation rule. |
stream | Definition of which objects your automation rule should apply to. |
action | Definition of what actually happens once the selected objects meet all conditions. |
While it’s technically possible to define multiple rules in a single JSON file, we strongly recommend defining one rule per file. This approach improves clarity, simplifies naming, and makes it easier to manage and update your automation rules over time.
Triggers
Let’s start with what gets your automation running.
In Dawiso, triggers are the events that activate an automation rule. You can think of them as the starting point: When something specific happens in the system, your automation kicks in. There are two main types of triggers:
- Event-based triggers run when a defined change happens, like someone updating a field or adding a new object.
- Scheduled triggers run at regular time intervals, for example, every day at 8:00 AM. You can set them to run as often as once per hour.
Here is how you configure a trigger:
"triggers": [
{
"key": "",
"type": "",
[second mandatory property]
}
]| Property | Description |
|---|---|
key | Unique key of the trigger. |
type | The trigger type. Depending on the type, there will be one more mandatory property, which will specify the values of the trigger. For example, the attributeChanged trigger type will require you to also define what attributeTypeKeys it’s applicable for. |
value or cronPattern | For event-based triggers, you will need to provide asset keys in the following format packageKey_assetKey. For scheduled triggers, you will need to define a CRON pattern. For a detailed guide on how to set it up, see our documentation on Triggers. |
Dawiso offers a wide range of triggers, and the list continues to grow. Here are some common categories:
| Trigger Type | Description |
|---|---|
| Ingestion and automation events | Triggers can fire when metadata ingestion finishes or when another automation rule completes. This is useful for chaining automations or responding to regular system updates. |
| Object lifecycle events | Automations can respond when objects are added or deleted — for example, when a new dataset is created or a glossary term is removed. |
| Workflow state changes | Triggers can activate when an object moves from one workflow state to another, such as moving from Draft to Review or Approved. |
| Attribute changes | When a user modifies specific attributes (like descriptions, titles, or custom fields), an automation can respond accordingly. |
| Comments and replies | Adding, editing, or deleting comments or replies can trigger automations — for example, to notify a data steward or escalate a question. |
| Relations and user roles | Triggers are available for changes in relationships between objects or user role assignments, such as when a new Steward is assigned or a dependency is added between datasets. |
Dawiso aims to cover a wide range of use cases so you can tailor your automation rules to fit your specific workflows. To support evolving needs, the list of available triggers continues to grow over time. For the full list of available triggers, refer to our Triggers documentation.
Trigger Examples
Example 1: Automation can be triggered by workflow states changing from the Draft or Review states.
"triggers": [
{
"key": "workflowStateChanged",
"type": "workflowStateChanged",
"workflowStateKeys": ["core_draft", "core_review"]
}
]Example 2: A new object (a document set) is added.
"triggers": [
{
"key": "objectAdded",
"type": "objectAdded",
"objectTypeKeys": [
"core_documentation_document_set"
}
]Example 3: Comments have been modified.
"triggers": [
{
"key": "commentAdded",
"type": "commentAdded",
"commentTypeKeys": ["comment", "issue", "question"]
},
{
"key": "commentDeleted",
"type": "commentDeleted",
"commentTypeKeys": ["comment"]
},
{
"key": "commentChanged",
"type": "commentChanged",
"commentTypeKeys": ["comment", "issue", "question"]
},
{
"key": "commentReplyAdded",
"type": "commentReplyAdded",
"commentTypeKeys": ["comment", "issue", "question"]
},
{
"key": "commentReplyDeleted",
"type": "commentReplyDeleted",
"commentTypeKeys": ["comment"]
},
{
"key": "commentReplyChanged",
"type": "commentReplyChanged",
"commentTypeKeys": ["comment", "issue", "question"]
}
]Streams
The stream defines which objects your automation rule should apply to. It acts as a filter between the trigger and the action, helping you narrow down the dataset to only the relevant items.
This step is essential as a well-configured stream ensures that only the right objects move forward in the automation pipeline. Without proper filtering, your rule could unintentionally affect the wrong objects or users and cause irreversible damage. Careful configuration of your stream ensures your automation runs precisely where you need it.
You can filter and select objects based on properties like type, state, relations, or even connected users. The available stream options give you flexibility to target the right data, and they’re continuously being improved and expanded to support more use cases over time.
A stream is configured using the following blank template:
"stream": [
{
"key": "",
"type": ""
}
]| Property | Description |
|---|---|
key | Unique key of the stream. |
type | The stream type. Depending on the type, there may be other mandatory properties. For example, the logicalFormula stream type will require you to define its clauses, while selectParent or selectChildren do not need any other properties. |
You can define the stream using a logical formula or by selecting objects through various relationship-based methods.
| Stream Type | Description |
|---|---|
| Logical formula | Filters objects using conditions that combine attributes, types, and other criteria. |
| Relation-based selection methods | These select objects based on their relationships with other objects or users. Depending on your needs, you can: Select related objects (via a specific relation type), Select child or parent objects, Select users connected to each object (e.g., Owner, Steward) via a user relation You can, of course, always include the original object in your selection as well, if needed. |
For an up-to-date list of available streams, see the documentation on Streams.
Example Stream
Click here to show the example.
"stream": [
{
"key": "logicalFormula",
"type": "logicalFormula",
"operator": "and",
"clauses": [
{
"type": "spaceFilter",
"operand": "in",
"values": ["Example Space"]
},
{
"type": "applicationFilter",
"operand": "in",
"applicationKeys": ["core_documentation_app"]
},
{
"type": "objectTypeFilter",
"operand": "in",
"objectTypeKeys": ["core_documentation_document_set"]
},
{
"type": "workflowStateFilter",
"operand": "notIn",
"workflowStateKeys": ["core_canceled", "core_expired"]
}
},
{
"key": "selectUserObjectRelation",
"type": "selectUserObjectRelation",
"userRelationTypeKeys": ["core_steward"]
}
]In the next section, we’ll define the final piece of the automation rule: the actions.
Actions
The final part of your automation rule are the actions. This defines what actually happens once the selected objects meet all conditions.
You can configure one or multiple actions to be performed on the filtered data. These actions let you automate updates, notify the right people, or even interact with external tools.
Let’s take a look at the blank template for actions:
"actions": [
{
"key": "",
"type": ""
}
]| Property | Description |
|---|---|
key | Unique key of the action. |
type | The type of the action. Depending on the selected type, you will need to also add other mandatory properties. For example, if you choose the sendNotification, you will need to provide a notificationTemplateKey. When changing an attribute (using the setAttribute action type), you must define what attribute it changes (attributeTypeKey) as well as what the new value should be (expression). |
Currently supported actions include:
- Sending notifications: Automatically notify selected users, such as Stewards or Owners, to keep them informed or prompt them to take action.
- Modifying attributes: Update a specific field on an object, like changing its status or priority.
- Changing workflow states: Move an object to a different workflow step (e.g., from Draft to Review).
- Writing back to Tableau: Push information like column descriptions from Dawiso into Tableau, keeping your reports well-documented.
Each action brings its own set of parameters, giving you the flexibility to tailor it to your use case. Whether you want to automate handoffs, enforce standards, or keep people in the loop, actions help you turn insight into impact.
As with triggers and streams, this list of actions is continuously evolving to support even more use cases. For the full list of available actions, refer to our Actions documentation.
Now let’s take a look at some practical examples.