External Web Request Trigger Sets

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.

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 Request" steps, 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

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

On Task Types:

Inbound / Outbound Tasks trigger according to your Distribution Policy assigned to your service. Your service can act in either direction (or both).
External Tasks are triggered via LUCS API. Also read the related Use Case on how to Manage External Tasks.
Conversation as a Service is a configuration that allows Agents to use the Impersonation Functionality.
Outbound / Callback Task Configuration Tasks are triggered from either the LUCS API or the Frontend. Also see the related Use Case: Supervisor initiates Callback from Lost Task Widget.

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
= Supported with LUCS 3.4 and up.
= 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..

Originator	Task Type					Trigger Event	Related Workflow Activities	Related System / Service Context Parameter
	IB	OB	ET	CS	CB
Agent						On Accept - Service conversation accepted by Agent	-	-
						On Created - Agent triggers Conversation As e.g. via LUCS API	-	-
						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	-	-
						On Transfer - Agent successfully transfers call	-	See "LastAgentTransferType" Parameter chapter below
Customer						On Accept - Conversation is accepted by ICH (IB) or Customer accepts conversation (OB, CS, CB)	"Accept Call" (IB)	-
						On Dialout - ICH starts calling to the customer	-	-
						On Calling - First notification of the conversation in system	-	-
						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"	-
						On Not Accepted - Customer doesn't accept the dialout/outbound conversation from ICH	-	-
						On Terminate - Customer leaves call	-	-
System						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						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	-	-
						On Terminate - Target not known to the system (not an agent, not a service) leaves call after a transfer by agent	-	-
Task						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.

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.

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

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"
}

XML

Within the External Web Request Trigger Sets dialogue, set a Trigger for: Agent - OnTransfer
Receive a service call on any Agent
Make a native Transfer call to another Agent → The trigger should be fired with the Parameter LastAgentTransferType