System Events are internal Torq events triggered by changes and actions within your Torq workspace. You can build specific logic and conditions to limit the trigger scope or create global logic by leaving the trigger as is and running your workflow upon every event. These triggers allow consistent upkeep of a workspace and ensure that failures and requests are promptly handled.
How to use
Go to Build > Workflows.
Select Create Workflow.
Select the System Events trigger.
Click Pick scenario.
Select from the available triggers:
Workflow failure
Trigger an alert upon any workflow within your workspace failing, or use conditions to trigger a failure alert for a specific workflow or group of workflows. Use tags, workflow ID, workflow creator, and more to create conditions for targeted failure alerts, providing an efficient way to monitor workflow performance.
Click Create workflow > System events > Pick scenario > Workflow failure.
If you want global monitoring logic that runs upon any workflow failure, leave the default trigger and start building your workflow using whatever logic best suits you (chatbot notification, nested workflows, etc.)
If you have a more specific use case, click on the trigger and click Add condition.
Build the appropriate conditions for your workflow using event context, including:
Event context | Definition |
{{ $.event.output }} | The output the workflow generated. |
{{ $.event.revision_id }} | The unique identifier of the executed workflow revision. |
{{ $.event.started_at }} | The timestamp when the workflow failed. format: "date-time" example: "\"2020-01-01T00:00:00Z\"" |
{{ $.event.status }} | The status code of the workflow failure. |
{{ $.event.updated_at }} | The timestamp when the workflow was last updated. format: "date-time" example: "\"2020-01-01T00:00:00Z\"" |
{{ $.event.workflow_id }} | The ID of the workflow whose review request you would like to trigger this system workflow. |
{{ $.event.workflow_name }} | The name of the workflow whose failure you would like to trigger this system workflow. Note that this condition will not automatically adjust if the name is changed. |
Step failure
Trigger a workflow upon any step failure within your workspace. If you want to trigger only for certain step failures, you can use conditions to specify a step by using the step name, type, or other conditions, such as the workflow name the step is in.
Click Create workflow > System events > Pick scenario > Step failure.
If you want global monitoring logic that runs upon any step failure, leave the default trigger and build your workflow using whatever logic best suits you (chatbot notification, nested workflows, etc.)
If you have a more specific use case, click on the trigger and click Add condition.
Build the appropriate conditions for your workflow using event context, including:
Event context | Description |
{{ $.event.ended_at }} | The timestamp when the step execution ended. format: "date-time" example: "\"2020-01-01T00:00:00Z\"" |
{{ $.event.execution_id }} | The unique identifier of the workflow execution. example: "\"74e19393-3e94-48d2-8b60-26f2d2665942\"" |
{{ $.event.execution_pretty_id }} | The unique identifier of the workflow execution in an easier-to-read, user-friendly format. |
{{ $.event.ignore_failure }} | The setting of the `Ignore failure` toggle in the step `Execution Options`. If set to Yes, the workflow will continue to run and may finish successfully even if this step fails. |
{{ $.event.started_at }} | The timestamp when the step execution started. format: "date-time" example: "\"2020-01-01T00:00:00Z\"" |
{{ $.event.step_execution_id }} | The unique identifier of the step execution. |
{{ $.event.step_image }} | The executed step image version that runs in the container. This field only applies to container-type steps and will be empty for operators. |
{{ $.event.step_name }} | The display name of the step whose failure you want to trigger the workflow. |
{{ $.event.step_runner.name }} | Information about the step runner. Only applicable for container-type steps (not operators) using a self-hosted runner. This field will be empty if the step is an operator or the Torq runner executes it. |
{{ $.event.step_status.code }} | The status of the step execution. |
{{ $.event.step_type }} | The type of the executed step. The type for API-based and utility steps is CONTAINER. For operators, the step type will include the operator name. |
{{ $.event.step_uuid }} | The step ID. You can access any step's ID by opening the step's YAML. This identifier will remain constant across the executions of the specific workflow, while the step name may change. The UUID will be different for the same step in the context of a different workflow. |
{{ $.event.workflow_id }} | The ID of the workflow whose failure you would like to trigger this system workflow. |
{{ $.event.workflow_name }} | The name of the workflow whose failure you would like to trigger this system workflow. Note that this condition will not automatically adjust if the name is changed. |
{{ $.event.workflow_revision_id }} | The unique identifier of the executed workflow revision. |
Request for review
Trigger a workflow upon a user requesting a review of a created or changed workflow. By default, the workflow will be triggered upon any request for review within your workspace, or you can specify workflows or users by using conditions.
Click Create workflow > System events > Request for review.
If you want global monitoring logic that runs upon any review request, leave the default trigger and build your workflow using whatever logic best suits you (chatbot notification, nested workflows, etc.)
If you have a more specific use case, click on the trigger and click Add condition.
Build the appropriate conditions for your workflow using event context, including:
Event context | Definition |
{{ $.event.created_at }} | The timestamp when the review was requested. format: "date-time" example: "\"2020-01-01T00:00:00Z\"" |
{{ $.event.description }} | The workflow description. |
{{ $.event.requested_reviewers }} | The reviewers requested. |
{{ $.event.tags }} | The tags on the workflow. |
{{ $.event.time_saved }} | The time saved in the Timeback parameter. |
{{ $.event.url }} | The URL of the workflow. |
{{ $.event.workflow_id }} | The ID of the workflow whose review request you would like to trigger this system workflow. |
{{ $.event.workflow_name }} | The name of the workflow whose failure you would like to trigger this system workflow. Note that this condition will not automatically adjust if the name is changed. |
{{ $.event.workspace_name }} | The ID belonging to the workspace the workflow is contained within. |
{{ $.event.workspace_id }} | The name of the workspace the workflow is contained within. |
{{ $.event.revision_id }} | The unique identifier of the executed workflow revision. |
{{ $.event.triggered_by }} | The name of the user who triggered the revision request. |
Share request created
Trigger a workflow upon a request to share a resource with the workspace. By default, the workflow will be triggered upon any share request within your workspace, or you can specify workflows or users by using conditions.
Click Create workflow > System events > Share request created.
If you want global monitoring logic that runs upon any review request, leave the default trigger and build your workflow using whatever logic best suits you (chatbot notification, nested workflows, etc.)
If you have a more specific use case, click on the trigger and click Add condition.
Build the appropriate conditions for your workflow using event context, including:
Event context | Definition |
{{ $.event.created_at }} | The time when the share request was created. |
{{ $.event.created_by }} | The email of the user who created the share request. |
{{ $.event.destination_workspace_id }} | The ID of the workspace the resource is shared with. |
{{ $.event.expires_at }} | The time when the share request will expire. |
{{ $.event.organization_id }} | The ID of the organization of the source and destination workspaces. |
{{ $.event.request_id }} | The unique identifier of the share request. |
{{ $.event.resource_id }} | The ID of the resource to be shared. |
{{ $.event.resource_name }} | The name of the resource to be shared. |
{{ $.event.resource_type }} | The type of resource to be shared. |
{{ $.event.scenario_id }} | The trigger scenario: "\"SHARE_REQUEST_CREATED \"" |
{{ $.event.source_workspace_id }} | The ID of the workspace from which the resource is shared. |
{{ $.event.state }} | The state of the share request: "\"SHARING_STATE_PENDING\"" |
Variable updated
Trigger a workflow upon an update to a table workspace variable. Set trigger conditions to execute the workflow only for specific updates.
This trigger applies only to table workspace variables. Updates to other variable types will not generate trigger events.
Click Create workflow > System events > Variable updated.
(Optional) To execute the workflow only for specific updates, click the trigger and select Add condition. Define conditions for your trigger using the event context, including:
Event context | Definition |
{{ $.event.table_name }} | The name of the table that was updated. |
{{ $.event.scenario_id }} | The trigger scenario: "\"VARIABLE_UPDATED\"" |
{{ $.event.triggered_by }} | The entity that updated the table workspace variable, including workflow ID and execution ID for workflows, or email for users. |
{{ $.event.data }} | Displays the previous and new variable values, along with details of the entity that created the variable, creation time, the entity that last updated it, and the update time. For table workspace variables, the updated row ID, column name, and new value are provided. |
{{ $.event.action }} | The action that was performed to update the table variable: CHANGE_ACTION_INSERT/ |
{{ $.event.timestamp }} | The time when the table workspace variable was updated. |