Skip to main content

Workflow triggers

Learn about triggers in your workflows.

Triggers are responsible for initiating the execution of a workflow. An event in your application can automatically start your workflow, or your workflow may be manually triggered by running a form in Slack.

The events that automatically trigger your workflows may come from various applications, such as HubSpot or Jira, when a specific event occurs, such as creating a new deal or updating an existing issue.

A manual trigger in a workflow refers to a mechanism where the workflow is activated by running a form in Slack manually, as opposed to being automatically triggered by an event in your applications. A manual trigger can be used to initiate a workflow when a user manually enters specific data or when an action needs to be performed on demand. For example, a user could run a form in Slack to initiate a workflow that creates a channel dedicated for a particular purpose or performs a specific action within an application.

Trigger types

Every workflow starts with a trigger. Depending on how a trigger starts a worklow, triggers can be grouped as manual triggers, webhook triggers and integration triggers.

Manual triggers

Manual triggers refer to specific types of workflows that can be initiated manually within Slack. Workflows with a manual trigger can be run

  • By calling /actioner command in Slack and selecting the workflow to be run.
  • By clicking on a button in a notification in Slack.
  • By selecting an option or clicking a button on the output view of another workflow.

In each of these cases, the manual trigger serves as the starting point for the workflow, allowing users to initiate the workflow directly from within the Slack platform.

Manual triggers are used for launching automated processes which only need to be kicked off exactly when you say. Unlike scheduled triggers or those reliant on external input, manual triggers provide the ability to initiate workflows on demand. They are commonly used to gather information from end users via a form in Slack, enabling the user input to be collected and to trigger subsequent nodes. The data obtained from users can then be used in the workflow to perform specific tasks or processes.

Webhook triggers

Webhooks capture events happening in your tools. When an event happens in your tool, your system can send this data to a URL generated by a workflow in Actioner.

Webhook triggers initiate workflows in response to HTTP requests your systems. A webhook acts as a listener, waiting for specific events to occur. When the event occurs, the external system sends an HTTP request to the Actioner webhook's URL and triggers the associated workflow.

Webhook vs integration trigger

If Actioner has an integration with your tool, select the related trigger from the integration. If an integration with your tool is missing, you can select to start your workflow through a webhook event instead.

Integration triggers

Similar to webhook, you can start your workflow by adding a trigger from an integration. Each integration has its own triggers based on the event happening in that tool. For example, Slack integration contains events happening in your Slack workspace, such as an event that is triggered when a message is posted to a public channel event or an event that is triggered when an emoji reaction is added to a message in a Slack message. Another integration, Zendesk, contains events happening in your Zendesk account, such as when a ticket is created or updated, or when a new agent is added to your account.

Contact with Actioner team

We are actively working on extending our integrations list. Give us a shout and join our community if you are looking for an integration with your tool.

Conditions for trigger events

Trigger conditions are additional rules that define what kind of trigger events should be selected for processing.

For new Slack messages, you can specify that only messages sent to #it-requests or #hr-requests channels to be processed.

Trigger conditions

Trigger conditions generally do not monitor a field change, but simply check if the trigger condition is fulfilled. Conditions in a trigger are evaluated after the event is fetched and its rules are evaluated against the receieved data.

To add a rule or set of rules to process your event, navigate to first node in your workflow and open Trigger conditions section.

  • To add new rules, click + button.

  • To remove rules, click 🗑 button.

Condition types

  • All events: When selected, the workflow will match every data that's evaluated against it and proceed to executing its nodes. No specific condition is specified when this option is selected.

  • One or more conditions below: When selected, if any one of the conditions are satisfied, it's sufficient to proceed to executing the nodes.

  • All conditions below: When selected, if all of the conditions are satisfied, it's sufficient to proceed to executing the nodes. If any of them fails, steps will not be executed.


Using a condition operator, you can also specify whether or not to run following nodes. Condition operators let you build complex condiition logics with the data from your events or inputs and from responses of actions in your workflows.