Previously defined External Web Requests can be combined in trigger sets. Once assigned within the Service Workflow Configuration the web requests in a trigger set will be called autonomously and independent from any "External Web Request" workflow steps.

(tick) Precondition: To access and assign Trigger sets you need to have the "Role Based Access - RBAC "ServiceExtended" Administrator role. 

The "External Web Requests Trigger Sets" page is accessible via Settings -> Service section -> "External Web Requests Trigger Sets"

Application in Services

Trigger sets must be applied in the "Trigger" section within the Service Workflow Configuration and are immediately effective.

Note that trigger sets can be used in combination with "External Web Request" Workflow Elements used in Workflow Instances assigned to a Service. This may lead to conflicts when connecting to external systems multiple times throughout a call. Take note:  

  • When requesting new tokens from external systems using "External Web Requeststeps, these manual steps should occur before an automated trigger event using the same External Web Requests item.
  • Both web requests and triggers may (re-) use the same Service Parameters as container variables. Values inside these parameters may be overwritten when the same web requests are used multiple times throughout an ongoing call / workflow.
  • You can use multiple instances of the same web request within a trigger set. The same overwrite to Service Parameters as container variables may therefore occur.

To avoid data being overwritten in an uncontrolled manner we recommend to work with trigger sets for consistency whenever possible and use web request steps in your workflows only when necessary or preferably using separate External Web Requests items not used in any existing trigger sets.

Trigger Event Types

Related Pages

(tick) External Web Requests need to be configured to appear as assignable trigger events.
(info) For the "Workflow Activities" column from the table above refer to the: Workflow Elements and Call Activites respectively.

On Task Types:

Trigger Events occur based on Originator and Task Type
  • IB = Inbound Task
  • OB = Outbound Task
  • ET = External Task (e.g. API)
  • CS = Conversation as a Service
  • CB = Callback Task
  • (tick) = Supported with LUCS 3.4 and up.
  • (plus) = Requires update to LUCS 3.7.

The trigger occurrence also depends on related workflow activities, which can (silently) update System / Service context parameters whenever they occur within your workflow..

OriginatorTask TypeTrigger EventRelated Workflow ActivitiesRelated System / Service Context Parameter



On Accept - Service conversation accepted by Agent


On Created - Agent triggers Conversation As e.g. via LUCS API--

(tick)On Proposal - Agent request gets solved by AM (Agent Manager)--


On Ringing - Service conversation is ringing at Agent



On RONA - Service conversation reached RONA timeout at agent



On Terminate - Agent leaves call


(plus)(plus)On Transfer - Agent successfully transfers call-

See "LastAgentTransferType" Parameter chapter below


On Accept - Conversation is accepted by ICH (IB) or Customer accepts conversation (OB, CS, CB)

"Accept Call" (IB)-

(tick)(tick)On Dialout - ICH starts calling to the customer--


On Calling - First notification of the conversation in system--


(tick)On In Queue - Once Customer enters Agent Queue where the Distribution Policy is applied.
  • "Send AgentRequest"
  • "Ask for Agent"


On Queue Left - Agent request gets terminated (e.g. because MaxRonaTries reached, MaxWaitTime. Customer is leaving the queue.
  • "Cancel Agent Request"
  • "Connect"

(tick)(tick)On Not Accepted - Customer doesn't accept the dialout/outbound conversation from ICH--


On Terminate - Customer leaves call


(tick)On Created - Callback request is created in the workflow"Create Callback Request"-


On Terminate - Call gets terminated by System (e.g. WF-Activity "Disconnect call")

  • "Disconnect Call"
  • "Decline"


On Transfer - Call gets transferred (by System) in WF (Virtual transfer, blind transfer, language dependent transfer)

  • "Virtual Transfer"
  • "Blind Transfer"
  • "Language Dependent Transfer"


On Voice Mail - Call gets sent to voicemail (WF-Activity "Conversation recording")

  • "Conversation recording"
External Transfer Target(tick)(plus)

On Ringing - Service conversation is ringing at a target not known to the system (not an agent, not a service) after a transfer by agent



On Accept - Service conversation accepted by target not known to the system (not an agent, not a service)  after a transfer by agent


(plus)(plus)On Terminate - Target not known to the system (not an agent, not a service) leaves call after a transfer by agent--


On Accepted - External Task has been delivered over LUCS API--


On In Queue - External Task is being enqueued to be solved/distributed to an agent--


On Terminate - External Task is finished--

Trigger Order / Synchronism

By default all added Web Request triggers are sorted by their ID and will be executed in the given order. Entries can be marked as either synchronous, which works as follows:

  • By default each entry is "Asynchronous", so LUCS will not wait for a remote System response before continuing with the next request.
  • In order to bypass this, each trigger may be enabled as "Synchronous", which will enforce waiting for a remote System response before executing the next request. The maximum wait time is defined by the "timeout" parameter on the "External Web Request" workflow activity.

(warning) Note that too many asynchronous triggers - while improving throughput - may result in "race conditions" and unexpected overrides of variables when triggers access the same data.

In this example, Request 1 is marked as synchronous, waiting for a system response. Once done, Request 2 may continue running in parallel while the System will already process Trigger 3.

LastAgentTransferType System Parameter

To offer contextual information about the last transfer initiated by an agent a new Service Context Parameter called "LastAgentTransferType" has been added in LUCS V3.4.

(lightbulb) The parameter stores the last type of a transfer triggered by an agent via API or native in the client (SfB/Teams).

By default this parameter is set to "None". It changes changes for every "OnTransfer" trigger for an Agent occurs, to any of the following types: 

  • APIBlind
  • APIConsultative
  • APIAttendant
  • NativeAttendant
  • NativeConsultative

How to use

  1. Create an external Web request that uses the "LastAgentTransferType" parameter in the response content body:

    Example Json Content

    	"lasttransfer": "LastAgentTransferType.Value",
    	"agent": "AgentSipUriWithoutSipPrefix.Value",
    	"caller": "CallerTelNumber.Value"
  2. Within the External Web Request Trigger Sets dialogue, set a Trigger for: Agent - OnTransfer 
  3. Receive a service call on any Agent
  4. Make a native Transfer call to another Agent → The trigger should be fired with the Parameter LastAgentTransferType