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 RequestWorkflow 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.

(lightbulb) 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 NameDescription

Name

Request name.

Organization Unit

Organization units to which the web request will be available.

Description

Additional description.

Authentication

  • No Authentication (Default)
  • BasicAuthentication(Base64)

(info) Enables additional fields (Username and Password) for login when enabled.
(info) 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. 

(info) The use of Placeholders or Service Parameters is supported.

Timeout

Timeout in hh:mm:ss for a request

(info) If set to 0, timeout is disabled

Server URL

Either full URL or fragments substitution with Placeholders or Service Parameters

(info)If placeholders or parameters are used, supported format is <(placeholder|parameter name).Value> only.

(lightbulb) 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.

(info) 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.

(info) Also see info below

Parameter to store Response Header

Allows to temporarily store the response header into a Service Parameterse.g. to react in a Workflow Instances "Switch" activity during an active session.

(info) 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. 

(lightbulb) 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. 

(lightbulb) 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.

(info) 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 DBWorkflow Element within a workflow.

(warning) 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.

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