Concepts
This document defines key concepts used throughout the Domino platform.
Last updated
This document defines key concepts used throughout the Domino platform.
Last updated
An represents a configurable workflow within Domino. It's triggered by specific events (like a manual start, a webhook, or a schedule) and executes a series of predefined steps or actions. Automations can be built visually with the builder. They can accept and use variables to customize their execution. Automations are central to orchestrating tasks, managing resources, and implementing custom logic within the Domino platform.
A Run represents a single execution instance of an Automation. When an Automation is triggered, it initiates a Run. Each Run is tracked with a unique ID, status (e.g., running, success, error), start and end times, the event data that triggered it, and any resulting output or errors. The Run entity stores this history, allowing users to monitor the execution flow, troubleshoot failures, and understand the outcome of each automated process. Runs are crucial for logging, auditing, and debugging automation performance.
are data parameters provided to an Automation or its individual steps to control their behavior. Automations can define a list of inputs specifying the expected data structure, including name, type, and whether it's required. These inputs can be set when creating or updating an Automation, often populated from templates or user configuration. During a Run, steps within the Automation can access these global inputs, as well as receive inputs (outputs) from preceding steps, enabling dynamic data flow and customization throughout the workflow execution.
are dynamic placeholders used within an Automation Run to store and pass data between steps. They allow for more complex logic and data manipulation. Variables can be explicitly set using actions like Set Variable or Set Array, specifying a name, type (String, Number, Boolean, Object, Array), and value. They can also be scoped. Other steps can then reference these variables using template syntax (e.g., {{variables.myVariable}} or {{variables.myScope.myVariable}}) to access their stored values, enabling data reuse and conditional execution paths within the automation. Variables exist only for the duration of a single Run.
The Builder refers to the user interface within Domino used for creating and editing . Domino supports two versions: v1, which uses a list-based approach to define triggers and actions sequentially, and v2, which provides a visual, node-based canvas for connecting steps (triggers, actions, conditions, loops) together. Certain actions or triggers might only be available in a specific builder version. The Builder is the primary tool for designing the logic and flow of automated workflows.
provide a structured way to store and manage data within Domino, similar to a database table or spreadsheet. Each Table belongs to an organization and has a defined set of Columns, each with a specific name, data type (e.g., String, Number, Boolean), and other optional constraints. Data is stored in Records (rows), where each record has a unique ID and holds values corresponding to the defined columns. Automations can interact with Tables in various ways: they can be triggered when records are created, updated, or deleted, and actions within automations can create, read, query, update, or delete records in a Table. Tables offer a flexible data storage solution directly integrated with the automation engine.
Folders serve as organizational containers specifically for Automations within the Domino platform. Each folder belongs to a user and an organization and can be created, named, updated, or deleted via the API or UI. Automations can be assigned to a folder upon creation or updated later. A special "Home" folder exists implicitly to house automations that haven't been assigned to a specific user-created folder. Folders help users manage and categorize their automation workflows.
A represents a campaign or challenge within the Domino platform, often aimed at user engagement or specific actions. Quests are composed of one or more that users need to complete. They can be created from scratch or based on predefined templates. Quests have a lifecycle, starting as a draft and becoming active when launched to a specific platform (like Zealy or a ). Automations play a key role in quests, handling , and potentially triggering or follow-up actions. Quests can have requirements like connected social accounts or specific wallet types.
In Domino, a primarily refers to an individual action or step that a user must complete as part of a Quest. Tasks can be predefined built-in types (like "Submit URL", "Retweet a Tweet", "Quiz") or created from reusable templates, allowing for custom actions. Each task within a Quest can have specific configurations and input requirements. When a Quest is launched, Domino often creates dedicated Automations (Task Validation automations) responsible for of each task based on user input and predefined logic.
The refers to the user-facing web interface or API layer provided by Domino for interacting with specific communities and their associated Quests. It allows end-users to discover available quests within a community, view quest details and tasks, submit , and manage their user profile, including connected wallets and social accounts.
Within the Domino Portal, a serves as a way to group and organize related Quests that belong to a specific Community. Modules have a name and description and are primarily used in the user-facing Portal to structure how quests are presented to end-users. This allows the Portal to display quests categorized by their respective modules.