External Web Requests

Starting with LUCS 3.4 "External Web Request" Workflow Element properties have moved away from Workflow Instances and into a central "Web Requests" page for central management and assignment to Organization Units.

Good to know:

Workflow Instances containing Web Requests from LUCS version 3.3 or older will have their web request properties automatically imported into this view. The naming for these new requests will be "WI_<ImportedWorkflowInstancename>". Any used Service Parameters and other user-defined properties are imported over alongside.
Existing Web Request data entities appear as Pulldown the "External Web Request" Workflow Elements within your Workflow Instances.
Starting with LUCS 3.4 you can also add Web Requests within External Web Request Trigger Sets

Definition

Within the Web Requests tab you can define and share web requests and make them available across your Organization Units like any other data entities configured under your Common Service Settings. The most common use of Web Requests is within workflow steps and within External Web Request Trigger Sets.

As within other panels, you can make use of Service Parameters and Placeholders within web requests to react flexible when sending or receiving CRM data.

The ‘Web Requests’ page is accessible on Settings -> Service section -> "External Web Requests"

WebConfigurator - Web Requests Page

The 'Web Requests' page contains the following settings:

Control Name	Description
Name	Request name.
Organization Unit	Organization units to which the web request will be available.
Description	Additional description.
Authentication	No Authentication (Default) BasicAuthentication(Base64) Enables additional fields (Username and Password) for login when enabled. Within Username and Password the use of Placeholders or Service Parameters is supported.
Request Type	Define the request type of the HTTP request. Possible values are: POST, GET or PUT
Request Headers	Allows to add one or more request headers to the request The Header Name and Value are split by a ";" (semicolon). Example: `Name;Value;Name2;Value2` CODE or just `Name;` CODE ...if you want an empty header value. The use of Placeholders or Service Parameters is supported.
Timeout	Timeout in hh:mm:ss for a request If set to 0, timeout is disabled
Server URL	Either full URL or fragments substitution with Placeholders or Service Parameters If placeholders or parameters are used, supported format is <(placeholder\|parameter name).Value> only. This URL and the format depends on your external system. Example: `http://mycrm.com/create/callerPhoneNumber.Value` CODE
Parameter to store Response Code	Allows to temporarily store the response code into a Service Parameters for further handling during an active session. Also see info below
Parameter to store Response Content	Allows to temporarily store the response content into a Service Parameters for further handling, e.g. to display the Parameter as Service Call Context during an active session. Also see info below
Parameter to store Response Header	Allows to temporarily store the response header into a Service Parameters, e.g. to react in a Workflow Instances "Switch" activity during an active session. Also see info below
Response Content Parameter Mapping	Allows to map one or several LUCS-internal Service Parameters to save an external content parameter value. Example: your CRM system delivers a crmTicketID upon ticket creation which can be mapped to the LUCS-internal "TicketId"
Response Header Parameter Mapping	Allows to map one or several LUCS-internal Service Parameters to save an external header parameter value. Example: your CRM system delivers an responsible Agent URI upon ticket creation as header for the new ticket, which can be mapped to the LUCS-internal "AgentSipURI"
Content Type and Content	Selection Drop-Down with Multi-Line text field below. Allows for the following formats: JSON, XML, www-form-urlencoded, multipart, text-plain, text-xml. Content supports Service Parameters or Placeholders.

Storage of Web Request Responses

Your Service Parameters that store responses (e.g. Web Request Response Codes, Contents and Headers) are only stored during an ongoing session, discarded afterwards. If you need to permanently store parameter contents in the DB you need to use the "Save Parameters to DB" Workflow Element within a workflow.

Note that permanent records of very large responses (e.g. large Json construct from external systems) can put a lot of load on your database / logging with no added benefit.

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