Skip to main content
All CollectionsBuild AutomationsTriggers
Trigger Workflows with Torq System Events
Trigger Workflows with Torq System Events

Learn how to initiate workflows based on internal Torq Events.

Updated this week

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

  1. Select Create Workflow > New blank workflow.

  2. Select the System Events trigger and click Pick scenario.

  3. Select from the available triggers:

  4. (Optional) To run the workflow only for specific trigger events, apply trigger conditions. Click the trigger, select Add Condition, and define the conditions using the event context specific to each trigger type.

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.

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.

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\""
format: "uuid"

{{ $.event.execution_pretty_id }}

The unique identifier of the workflow execution in an easier-to-read, user-friendly format.
example: "\"AB-150488\""

{{ $.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.
example: "{\"code\": 9, \"message\": \"Internal error.\", \"verbose\": \"Contact support.\"}"

{{ $.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.

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.

Event context

Definition

{{ $.event.created_at }}

The time when the share request was created.
example: "\"2020-01-01T00:00:00Z\""

{{ $.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.
example: "\"2020-01-01T00:00:00Z\""

{{ $.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.
example: "\"RESOURCE_TYPE_WORKFLOW\""

{{ $.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.

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/
CHANGE_ACTION_DELETE/
CHANGE_ACTION_UPDATE

{{ $.event.timestamp }}

The time when the table workspace variable was updated.

Workflow published

Use this trigger to execute the workflow whenever a workflow is published within the workspace. For example, automate stakeholder notifications to enforce compliance, prevent errors, and enhance collaboration, similar to the Workflow unpublished trigger below. You can add trigger conditions to ensure the workflow executes only for specific Publish events.

Event context

Definition

{{ $.event.workflow_id }}

The ID of the published workflow.

{{ $.event.workflow_name }}

The name of the published workflow.

{{ $.event.revision_id }}

The ID of the published workflow revision.

{{ $.event.workspace_id }}

The ID of the workspace where the workflow was published.

{{ $.event.workspace_name }}

The name of the workspace where the workflow was published.

{{ $.event.url }}

The URL to access the published workflow.

{{ $.event.scenario_id }}

The trigger scenario: "\"WORKFLOW_PUBLISH\""

{{ $.event.tags }}

The tags attached to the published workflow.

{{ $.event.time_saved }}

The value specified for the workflow Timeback parameter, measured in nanoseconds (ns).

{{ $.event.description }}

The description of the published workflow.

{{ $.event.created_at }}

The timestamp when the workflow was initially created.

{{ $.event.triggered_by }}

The entity that published the workflow. This includes the user's name and email for manual publishing or the integration name with the user email or client ID if the Publish a Workflow step was used via private or service API keys.

Workflow unpublished

Use this trigger to execute the workflow whenever a workflow is unpublished within the workspace. For example, automate notifications to stakeholders to ensure compliance, avoid errors, and foster collaboration, similar to the Workflow published trigger above. You can add trigger conditions to ensure the workflow executes only for specific Unpublish events.

Event context

Definition

{{ $.event.workflow_id }}

The ID of the unpublished workflow.

{{ $.event.workflow_name }}

The name of the unpublished workflow.

{{ $.event.revision_id }}

The ID of the unpublished workflow revision.

{{ $.event.workspace_id }}

The ID of the workspace where the workflow was unpublished.

{{ $.event.workspace_name }}

The name of the workspace where the workflow was unpublished.

{{ $.event.url }}

The URL to access the unpublished workflow.

{{ $.event.scenario_id }}

The trigger scenario: "\"WORKFLOW_UNPUBLISH\""

{{ $.event.tags }}

The tags attached to the unpublished workflow.

{{ $.event.time_saved }}

The value specified for the workflow Timeback parameter, measured in nanoseconds (ns).

{{ $.event.description }}

The description of the unpublished workflow.

{{ $.event.created_at }}

The timestamp when the workflow was initially created.

{{ $.event.triggered_by }}

The entity that unpublished the workflow. This includes the user's name and email for manual unpublishing or the integration name with the user email or client ID if the Unpublish a Workflow step was used via private or service API keys.

Did this answer your question?