System Events trigger
  • 04 Feb 2024
  • 5 Minutes to read
  • Dark
    Light

System Events trigger

  • Dark
    Light

Article Summary

System Events are internal Torq events triggered by changes and operations within your Torq workspace. If a workflow or step fails, a request to share a resource with the workspace is initiated, or a user requests a review of their work, that event will trigger the start of a workflow created with any of the following triggers. 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 on every event.

How to use

  1. Go to Build > Workflows.
  2. Select Create Workflow.
  3. Select the System Events trigger.
  4. Click Pick scenario.
  5. Select from the available triggers:

Create a workflow with a system event trigger

Workflow failure

Trigger a failure alert system upon any workflow within your workspace failing, or use conditions for a specific workflow to make a failure alert. Use tags, workflow ID, workflow creator, or many other conditions to specify workflows. 

  1. Click Create workflow > System events > Workflow failure.
  2. If you want global monitoring logic that runs upon any workflow failure, leave the trigger as is and build your workflow using whatever logic best suits you (chatbot notification, nested workflows, etc.) 
  3. If you have a more specific use case, click on the trigger and click Add condition.
  4. Build the appropriate conditions for your workflow using event context conditions, including:
Event contextDefinition 
{{ $.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.  

  1. Click Create workflow > System events > Step failure.
  2. If you want global monitoring logic that runs upon any step failure, leave the trigger as is and build your workflow using whatever logic best suits you (chatbot notification, nested workflows, etc.) 
  3. If you have a more specific use case, click on the trigger and click Add condition
  4. Build the appropriate conditions for your workflow using event context conditions, including:
Event contextDescription

{{ $.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. The workflow will be triggered upon any request for review within your workspace, or you can specify workflows or users by using conditions. 

  1. Click Create workflow > System events > Request for review.
  2. If you want global monitoring logic that runs upon any review request, leave the trigger as is and build your workflow using whatever logic best suits you (chatbot notification, nested workflows, etc.) 
  3. If you have a more specific use case, click on the trigger and click Add condition.
  4. Build the appropriate conditions for your workflow using event context conditions, including:
Event contextDefinition
{{ $.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. You can use trigger conditions to filter specific trigger events.

  1. Click Create workflow > System events > Share request created.
  2. To add a trigger condition, click the trigger and then click Add condition.
  3. Use the event context to extract information about the trigger event:
Event contextDefinition
{{ $.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 the resource is shared from.
{{ $.event.state }}
The state of the share request: "\"SHARING_STATE_PENDING\""

The example below shows a workflow triggered by the Share requested created internal scenario. When a request to share a resource with the workspace is received, it can be sent to an admin Slack channel where the channel members can select to accept or deny it.

Automatically accept or deny a share request



Was this article helpful?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.