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.

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 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 Module inbound SMS, WhatsApp messages, and voice calls start Sessions. You never build the URLs by hand: with the Auto-Deploy toggles on, the Module registers its webhooks on your Twilio services automatically at every Deployment.
  • 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 fire is listed on the Scheduled Triggers page.

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.

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.