Skip to main content

Triggering Workflows

Connect chat, phone lines, Slack, schedules, and AI assistants to your deployed Process every trigger starts a Session.

A deployed Process does nothing until something starts it. Each start creates a Session one runtime execution of your Process on the Channel the trigger arrived through. This page explains the one identifier every trigger has in common, the Environment token, and walks through each way a Session can be started.

How it works​

Every Environment is identified by a unique Environment token a GUID assigned when the Environment is created. External systems never reference your Process by name; they reference this token. Telephony and Slack webhook URLs end with it, scheduled starts resolve through it, and the test chat panel selects an Environment before starting a conversation.

When a trigger arrives, the platform resolves the token to its Environment, loads the Process version deployed there together with that Environment's Module configuration, and starts a new Session on the trigger's Channel. The Session then appears on the Sessions page with its Channel and status.

Which Start Event runs​

A Process answers a Channel by having a Start Event for it: the StartTask for the Chat and API, and each Channel Module's own start for its Channel (a call start, a WhatsApp start, a Slack start...). The Session begins at the Start Event serving the trigger's Channel, which writes what the Channel received into one variable ({call}, {message}, ...).

  • A Process with a single Start Event runs it for every trigger. A Channel's own start refuses another Channel with error 8025.
  • Two Start Events serving the same Channel stop the Session with error 8024: keep one start per Channel.
  • Timer starts never run for a trigger; only their schedule fires them.

Two conditions must hold for any trigger to succeed:

  1. A Process version is deployed to the Environment otherwise the start fails with error 8004 EnvironmentNoVersionFound.
  2. The Environment is active a disabled Environment rejects every new Session with error 8002 EnvironmentNotActive.

Finding your Environment token​

  1. Open your Process in the BPMN editor.
  2. Open the Environments panel and select the Environment's tab.
  3. The Token row shows the token, next to the Active and Test switches.
  4. Click the copy icon to copy the token to your clipboard.
tip

The webhook URLs used by Channel Modules embed this token as their last URL segment. Each Module's page shows the exact URL shape to configure on the external service you never have to assemble one from scratch.

Ways to start a Session​

Chat the test chat panel​

Click Chat in the editor toolbar to open the test chat panel. Pick a deployed Environment from the Select environment dropdown and click Start a Session begins on the Chat Channel, at the Process's Chat start (or at its only Start Event, in test mode), and you can talk to your workflow directly. The chat implementations of the I/O Tasks come from the Standard Module.

Phone calls and messaging​

  • Aculab Module an inbound call starts a Session on the AculabVoice Channel. You paste the Module's start webhook URL (ending with your Environment token) into your Aculab Cloud inbound service; the webhook is protected by the Webhook Service Password you set in the Environment configuration.
  • Twilio: inbound SMS and WhatsApp messages start Sessions through Twilio Messaging (TwilioMessagingSms / TwilioMessagingWhatsApp Channels) or Twilio Conversations (TwilioSms / TwilioWhatsApp), and voice calls through Twilio Voice (TwilioVoice). You never build the URLs by hand: with the Auto-Deploy toggles on, each Module registers its webhook on your Twilio services automatically at every Deployment. See Which Twilio module?.
  • ACS Module inbound and outbound calls through Azure Communication Services start Sessions on the AcsPhone Channel.

Slack messages​

  • Slack Module a message in a connected Slack workspace starts (or continues) a Session on the SlackChannel Channel, scoped per channel, per thread, or per user depending on the Session Mode you configure.

Schedules​

  • Scheduler Module ScheduleRecurring and ScheduleOnce are alternative Start Events that start fresh Sessions on a timetable, and ScheduleReminder books a one-time future Session carrying custom data. Every pending run is listed on the Scheduled tasks page, where you can also set up a named repeat of any flow (in a time zone, with its own data and version) without changing the flow.

From another Process​

  • Some Tasks accept an Environment token as a property and start a separate Process with it for example the Aculab Module's handler workflows, which run a second Process when a recording or transcription becomes available. Both Processes must belong to the same Workspace.

AI assistants​

  • MCP Access an AI assistant connected to your Workspace over MCP can start test conversations with a deployed Process and drive them turn by turn, alongside the rest of the workflow toolset. It can test any Start Event from the chat: it names the start and passes the data the Channel would send (a caller's number, a WhatsApp message, a form's fields), and the start runs in test mode (isTest is true in its variable).

Direct API​

A direct HTTP start endpoint exists, but it is reserved for platform-level integrations and authenticated with credentials that are not issued to Workspace users. If you need to start Sessions from your own backend, contact support to discuss an integration.

Security​

The Environment token routes a trigger to the right Process it is an identifier, not a stand-alone credential. Each Channel authenticates its triggers in its own way: Aculab uses the Webhook Service Password and Slack the Signing Secret both set per Environment Twilio validates webhook signatures, and ACS gates call actions with tokens issued by Azure Communication Services itself. The test chat panel and MCP assistants require a signed-in Workspace member.

Even so, handle trigger URLs with care:

  • Share them only with the systems that need them. Anyone who knows a trigger URL can attempt to start Sessions against it.
  • Disable an Environment to shut its triggers down instantly. Turn off the Active switch in the Environments panel every new trigger is rejected with error 8002 until you re-enable it. There is no action to regenerate a token; to retire one for good, delete the Environment and create a new one, which receives its own token.
  • Keep test traffic out of production. Point systems under development at an Environment whose Test switch is on its Sessions are marked as test data and keep a separate production Environment with its own token and credentials.

Best practices​

  1. Configure the Channel credential before sharing a webhook URL set the Aculab Webhook Service Password or Slack Signing Secret in the Environment configuration first, then register the URL on the external service.
  2. Use one Environment per external system stage a Testing Environment for the sandbox account, a production Environment for the live one; each has its own token, configuration, and credentials.
  3. Verify with the Sessions page after wiring up a trigger, fire it once and confirm the new Session appears with the expected Channel.
  4. Disable rather than delete turning Active off stops triggers immediately and is instantly reversible; a deleted Environment is only recoverable by contacting support.