Social platforms (ServiceLink)¶

ServiceLink is a Windows based service, which receives and sends the messages among FrontStage and social media chats. Messages are received with help of webhooks, sending is realized by provider API. From agent’s perspective, chatting with users on social media, is no different than via any other channels in FrontStage.

It sends the recognized message content from the providers via ProServer to the synchronous service, where it is further distributed as a regular chat message to FrontStage agents. When an agent responds, their response is passed through ProServer to ServiceLink again. ServiceLink calls the appropriate provider API to send the agent’s message.

ServiceLink supports several kinds of providers - the current ones are Facebook and WhatsApp. We support Facebook API for Messenger, and WhatsApp is implemented using third-party provider Tyntec.

Important

For integration with social platforms, it is not necessary to install and configure WebSite (unlike the applications of WebChat, WebForm and others that are built on the WebSite module).

../../_images/social-network-support-overview.nol10n.png

Providers¶

FrontStage can be set up to receive and send messages/posts from social networks. These messages are distributed to agents in the same manner as any other chat types, and they work with them in the same user interface, too.

If you just need Facebook Messenger, ServiceLink offers built-in support for the social platform’s chat. Integration via Tyntec is available for WhatsApp.

Supported providers as of July 2023.¶
Social network	FrontStage	Tyntec
Facebook Messenger	yes	no
WhatsApp	no	yes
Zalo	yes	no

ServiceLink¶

In order for a given FrontStage installation to use integration with social platforms via ServiceLink, it is necessary to enable the SocialIM channel in the configuration parameter ChannelUsage.

Parameters can be configured within appsettings.json of this application.

Configuration file:

{
"Logging": {
    "LogLevel": {
      "Default": "Information",
      "System": "Warning",
      "Microsoft": "Warning"
    },
  "Console": {
    "FormatterName": "simple"
    },
  "ApplicationInsights": {
    "LogLevel": {
      "Default": "Information",
      "System": "Error",
      "Microsoft": "Error"
    }
  },
  "File": {
    "Path": "",
    "Append": true,
    "MinLevel": "Information",
    "FileSizeLimitBytes": 67108864,
    "MaxRollingFiles": 32
    }
  },
"DebugIndicators": "",
"ApplicationInsights": {
  "InstrumentationKey": null
  },
"Kestrel": {
  "Endpoints": {
    "Web": {
      "Url": "https://localhost:5020"
    }
  },
  "EndpointDefaults": {
    "Protocols": "Http1AndHttp2"
  },
  "Certificates": {
    "Default": {
      "Path": null,
      "Password": null
    }
  },
    "Limits": {
      "MaxConcurrentConnections": 100,
      "MaxConcurrentUpgradedConnections": 100
    }
  },
  "AllowedHosts": "*",
  "AppPathBase": null,
  "ServiceLinkAddress": "",
  "EnableSwagger": false,
  "PbxProxyParameters": null,
  "InstanceName": "#MACHINENAME#",
  "PeerAddress": "!iCC.ServiceLink",
  "PeerPort": null,
  "DatabaseCaching": 60,
  "ChatServiceRetention": 120,
  "TaskDelay": 50000,
  "DefaultCulture": "en-US",
  "ConnectingToTenantProxy": false,
  "TenantConnectionInterval": 60,
  "TenantProxyUrl": "https://tenantlinkweb.azurewebsites.net/api/TenantProxy",
  "Facebook": {
    "Url": "/api/facebook",
    "Active": false,
    },
  "Tyntec": {
    //WhatsApp
    "Url": "/api/tyntec",
    "Active": false,
    "BaseAddress": "https://api.tyntec.com/conversations/v3"
    },
  "Yext": {
    //Hitchhikers
    "Url": "/api/yext",
    "Active": false,
    "BaseAddress": "https://api.yext.com/v2/accounts/",
    "ApiVersion": "20210301"
    },
  "ChatBot": {
    "Url": "/api/chatbot",
    "Verbs": "GET,POST",
    "WebSocket": true,
    "Active": true
    },
  "Rest": {
    "Url": "/api/rest",
    "Active": true
    },
  "Zalo": {
    "Url": "/api/zalo",
    "Active": false,
    "BaseAddress": "https://oauth.zaloapp.com/v4/",
    }
}

Parameters¶

AllowedHosts - allowed domains, related to reverse proxy. More in official documentation
AppBathBase - root path to the application. Needs to be filled in a case, when the application is not stored in a root folder of the virtual storage.
InstanceName - FrontStage instance name, the value has to be the same as InstanceName config parameter (or the value in Configuration database table, InstanceName item)
ServiceLinkAddress - address, where ServiceLink is accessible - needed for internal methods usage
EnableSwagger - advanced logging option (for devs)
PeerPort - a port according to which the gateways and ServiceLink-ProServer-SynchronousService communications are being identiffied
PbxProxyParameters - pbxstring connection string to ProServer (Cti.Proxy connector). String consists of four parts - first is an IP or DNS of the ProServer (ProService or ProRelay service), second is the IP port (the negative number indicates a usage of the MsgPack transport), the third is a directional connection timeout [ms], the last parameter is a password
proserver,-18321,30000,TESTPWD
PeerAddress - ServiceLink address in the ProServerMSG sending system. Should be the same as within the gateway definition (Address item for a gateway using ServiceLink). If only one instance of SL is in use, the default value is !iCC.ServiceLink. More info in internal documentation.
DatabaseCaching - determines how ofter is ServiceLink contacting the database for information, whether the data in Configuration, ChatGateway and Gateway had been updated
ChatServiceRetention - sets a cache validity interval for ChatGateCondition.Signal with a particular TrackingId [m]
TaskDelay - an interval, for how long is ServiceLink going to be waiting for obtaining the values from an asynchronous servive, so it can order the ongoing chats (LiveChats) and signals (ChatGateCondition.Signal values)
DefaultCulture - a default localization culture in ISO5 (unless it needs to be specified by rules)
TenantProxy parameters described in section below
The particular services connectors and their settings can be considered, apart from one exception, as a constant. If you want to use a service, set parameter Active to true, otherwise to false. Even if you are not using a particcular service, do not delete it’s connector!

The rest of the parameters, which is not mentioned here, is highly technicall and needs to be taken care of with your consultant. More information in internal documentation.

TenantProxy service¶

A service that processes chat communication from Facebook and sends it on to the contact centre. Serves multiple contact centers at once. At the FrontStage level, it communicates with the ServiceLink component.

ServiceLink sends a signal with its ID to TenantProxy. It saves the connection and sets the time how long the connection will be active (it is extended with retries from the ServiceLink side). Each social network message is scanned through the corresponding channel, then identified by ID and sent to the appropriate ServiceLink instance (if active). If it does not find the connection, it returns “error” and the message is sent again - in the case of Facebook Messenger, a 60 min countdown is triggered during which the message must be received, otherwise the Webhook is disconnected.

Developer Account¶

It is only created once, on the service provider side, i.e. Atlantis.

Create a Facebook for Developers account that includes the “Messenger” and “Webhooks”
Application is registered under develop account - registered to provider
The app must have pages_messaging permission - allows you to use Facebook Messenger, including getting counterparty information
- access level must be Advanced access
- you can submit a request through App Review ‣ Permissions and Features
- this must then be processed on the Facebook side, this takes some time
Webhook - in Messenger ‣ Settings find the Webhooks section and set:
- Callback URL - Atlantis proxy address
- Verify token - selected authentication string
- Both parameters will be provided by the application developer on request

Service configuration¶

Set the parameters in the configuration file for TenantProxy (appsettings.json). All of them are mandatory.

TenantProxyVerificationToken - verification token for communication among TenantProxy and Gateways - each connection request is verified or discarded. GUID array. Every single GUID can verify access for a particular gateway or a group of them. The GUID itself can be random, the structure is not defined.
ConnectionExpiryTimeInSeconds - the connection activity interval maintained by both services. Until the interval expires, the connection must be renewed by the ServiceLink. It is recommended to set this value slightly higher than the TenantConnectionInterval parameter in the ServiceLink configuration. Integer. Default value = 65 [sec].
Connections - specification of service connections to social networks. JSON specification.
- Facebook
  - Active - attach activated/deactivated. Boolean.
  - VerificationToken - A verification token identical to the one specified on Facebook for Developers, entry Verify token. String, GUID.
  - AppSecret - parameter obtained from Facebook for Developers - unique for each application, but identical across pages of the same application. It is further used for calling the Meta SEND API and authentication. String.
  - FacebookURL - The URL extension for the TenantProxy that Meta Messenger sits on (part of the Webhook URL) - /api/facebook

{
"TenantProxyVerificationToken": "{GUID,GUID,...}",
"ConnectionExpiryTimeInSeconds": 65,
"Connections": {
  "Facebook": {
    "Active": true,
    "VerificationToken": "",
    "AppSecret": "",
    "FacebookURL": "/api/facebook"
  }
}}

Connect and configure Facebook Messenger¶

To connect to Facebook, FrontStage uses a TenantProxy server hosted and managed by Atlantis. This is a paid, cloud-based service that can be used to receive and send Facebook communications.

The commissioning of the messages is carried out in the following main steps:

Creating a contact account on Facebook (Facebook for Business) - by the party running the contact centre
Connecting the account created above with TenantProxy (Atlantis only)
Connecting TenantProxy together with ServiceLink inside FrontStage (consultant/admin)
Establishing a gateway and follow-up rules

Contact account¶

The customer must create a Facebook profile, which must have the category “Business”. It must have a public Facebook page associated with it. In the following steps, this will be connected to the account serving TenantProxy. You only need to know its name to connect.

Warning

The profile must not be connected to another automated service, such as a “chatbot”. This can cause a problem with message delivery to FrontStage!

TenantProxy connection¶

Through the developer account that serves TenantProxy, you connect the customer’s Facebook page to the service application and then set up ServiceLink on the customer’s installation to communicate with TenantProxy.

Adding a customer page¶

Go to “Business settings” under your account and continue:

Open Accounts ‣ Pages where there is a table of linked pages
Expand the menu under Add and select “Request access to Page”
In the following window, type the name of the page you want, then select it from the menu that appears
You need partial permissions to the page - check Partial access at the bottom (see the screenshot for particular permissions)
Press Request access

You must now wait for confirmation from the customer.

Important

If the customer’s account has a “confirmed authenticity page” (blue check mark after the name), the request will probably be rejected. The user must send an access request from their account (same procedure as above) to the address defined for TenantProxy (currently demo01@frontstage.cc)

Customer page settings¶

Here we assume that the accounts from the previous step have been linked.

Go to “Developer settings” under your account and continue:

Open Messenger ‣ Settings
To add a new customer, search Access Tokens (pages connected to the service)
- Add or remove Pages button - in the dialog box select Opt in to current Pages only when the list of currently enabled pages is displayed and just check the new one and continue the dialog until the end
- then press the Generate token button in the Tokens column for the newly added page
- You will use the token later when creating a gateway in FrontStage (JSON in the Device entry when creating the gateway)
Attention

Access tokens depend on rights and all other changes. When rights change, tokens change as well and need to be regenerated and updated
Set the range of data taken from the account
- Find the Webhooks section, which displays a table of customer sites
- Press the Add subscriptions button on the setup page.
- Check messages and confirm

Configuring ServiceLink to connect to TenantProxy¶

Establish and set the parameters in the configuration file for ServiceLink (appsettings.json).

ConnectingToTenantProxy - Specifies whether the ServiceLink connects to the TenantProxy. Boolean. True - Some Facebook functions are set to not be resolved by ServiceLink unless they arrive from TenantProxy.
TenantConnectionInterval - Interval how often the ServiceLink reports TenantProxy as active. If the ServiceLink does not report in time and a corresponding message from Facebook arrives at the TenantProxy, the message will be lost. Integer. Default value = 60 [sec].
TenantProxyUrl - Address of TenantProxy. String. https://tenantlinkweb.azurewebsites.net/api/TenantProxy

{
"ConnectingToTenantProxy": false,
"TenantConnectionInterval": 60,
"TenantProxyUrl": "https://tenantlinkweb.azurewebsites.net/api/TenantProxy",
}

Creating a Facebook gateway¶

Follow the gateway creation instructions , paying attention to the Device section when defining the gateway.

Possible form of Device for Facebook:

ServLinkFacebook {
         "PageAccessToken": "XXXXXXXXXXXXXXXXX",
         "AppSecret": "XXXXXXXXXXXXXXX",
         "PageName": "Frontstage - TestPage",
         "PageId": "123456789321",
         "AppId": "987654321",
         "ApiVersion": "v10.0",
         "InstantBannerMessages ": true,
         "TenantProxyVerificationToken": "GUID",
         "VerificationToken":"GUID"
   }

Parameters:

PageAccessToken - Token generated on Facebook for Developers (see above), used for calling Meta Send API methods (e.g. getting user details). It changes with each Permissions change on FB Developers and with each regeneration. String. Mandatory parameter.
AppId - application ID of the page. String. Mandatory parameter.
AppSecret - Security token generated on Facebook for Developers. Used to generate a security hash and for other communication. Generated for the AppId specified above. String. Required parameter.

../../_images/sl-facebook-devs-app.nol10n.png

PageId - ID of the associated Facebook page, which includes the Facebook application. String. Mandatory parameter.
PageName - the name of the page according to PageId. String. Mandatory parameter.
ApiVersion - API version that is used when calling “Send API” methods. Corresponds to the API version listed in the Webhooks (Facebook for Developers) submenu. String. Optional parameter. Default value set to “v8.0”
TenantProxyVerificationToken - A verification token that must correspond to the TenantProxy stored token. It is used to verify communication between services. GUID.

Important

Valid existing token will be provided on request. For the creation of a new token, please discuss it with your consultant.
VerificationToken - A verification token identical to the one specified on Facebook for Developers, entry Verify token. String, GUID.

InstantBannerMessages - parametr usable for more gateway types, see

Connecting and configuring WhatsApp (Tyntec)¶

Creating and configuring accounts¶

Customer: Create a Facebook Business Account on https://business.facebook.com.

Important

Facebook offers two account types: the “standard WhatsApp” and the higher “official WhatsApp Business”. The latter is basically just a green tick mark next to the account name, and only the most reputed global businesses can get it.
Customer: The account needs to be verified to indicate that it is a real company.
- Go to Business Manager ‣ Security Center and click on Start Verification.
- You may be asked to upload documents to prove that the account belongs to a real company. Accepted documents are listed here: https://www.facebook.com/business/help/159334372093366.
- Once the account is verified, it will be displayed with a green icon and the date of verification.
Customer: You must set up two-factor authentication for your account. Refer to the Security Center ‣ 2-factor authentication section of the guide.
Customer: Needs to supply account information to atlantis. The information cannot be changed later.
- Facebook Business ID
- The phone number that you want to associate with your WhatsApp account in the international format (the number must not be used for another WhatsApp account!)
- Account name
- Company description (max. 256 characters)
- Registered office (max. 256 characters) - street, house number, postcode, city, state, country
- Contact e-mail (max. 128 characters) - a public e-mail address used by the company
- Status (max. 139 characters) - status text displayed for the WhatsApp account
- Company website 1 (max. 256 characters) - URL of the website, Facebook profile, etc.
- Company website 2 (max. 256 characters) - URL of the website, Facebook profile, etc.
- Profile picture (min. 500x500, recommended 640x640, max. 5 MB) - ideally a rectangular shape
atlantis: Setting up a Tyntec account.

In the Tyntec online interface at https://my.tyntec.com/auth/login, you need to register, have a WABA (WhatsApp Business Account) account and set up a phone number and get an ApiKey.

The entire profile that is displayed to customers on WhatsApp is also set up using the Tyntec interface.
Customer: Confirm the request from Tyntec in the Requests section of Facebook Business Account administration.
Customer and atlantis together: The customer’s phone number needs to be verified.
- It takes place in close coordination - a specific day and time is agreed in advance
- We use WhatsApp’s autodial method, where an automated caller in English tells the customer the code, which is immediately passed to Tyntec and that completes the administration process.
After authentication, we get the API key from Tyntec.
atlantis: Webhook settings in the Tyntec account.

Setting up webhooks is more complicated. Their online interface does not currently allow this, so there are two options:
1. Contact Tyntec by e-mail and before instructions, to which apiKey you need to assign which webhook
2. Use the capabilities of Insomnnia, or similar software, and do the update using a REST API call
- Call PATCH https://api.tyntec.com/chat-api/v3/applications/default (the version may change in the future)
- body text/json
```
{
  "webhooks": [
    {
      "events": [
        "MoMessage"
      ],
      "callbackUrl":"https://demo.frontstage.cc:7443/api/tyntec"
    }
 ]
}
```
- Headers
  - “Content-Type” = application/json
  - “apiKey” = <apiKey>

Attention

In Tyntec, we always have to create a unique instance (cpass) for each telephone number/customer because, although it is possible to assign two or more tel. numbers to one instance and generate two or more unique API keys for it, the webhook is set the same automatically for all API keys.

Creating two instances for one cpass is therefore useless. You have to create a new “cpass” for each customer.

Zalo¶

Zalo is a Vietnamese social network and messaging and calling platform. It is the Asian equivalent of Facebook.

Account creation and settings¶

Create a personal Zalo account (you must have a local phone number ready)
Create an “Official Account” (hereinafter referred to as OA), it needs to be created by the customer on the company level (develop account is not sufficient)
Set up a personal account (from step 1) as an admin for OA (works analogous to Facebook, admin cannot be a person with an international number!)
Go to the developer section of your account and create a Zalo app (fill in the basic information needed). Activate it on the “Settings” tab using the “Active” switch.
Verify the domain that will serve as “Webhook”. Go to the “Domain Authentication” tab to get the confirmation html file
- Fill in “Domain” (Webhook)
- Press “Accuracy”
- Another settings dialog box will appear, where you will get the file
Following on from the previous step: at “DeploymentWeb” in the database DeploymentDB , add an entry to the table LiteralLookup where:
- LiteralGroup = 1000
- LiteralText = path to the authentication file stored on “DeploymentWeb”
- DisplayName = content of the retrieved html file
- (optional) Description = “ContentType” (e.g. “text/plain”)
Note

The content of the LiteralLookup table is read only at startup, after changing the data it is necessary to restart POD!
On the Official Account ‣ Official Account Management tab, link the previously created OA
On the Official Account ‣ General Settings tab, set the “Callback URL” - this is the address where the OA Token request response should be sent. (latest version remark: FrontStage has no active usage of this link. The presence of the link is an implementation requirement from Zalo but looks like the intended functionality doesn’t work on their side.)
After setting “Callback URL”, the “Link to request permission” item will appear on the page.

The OA admin (ATTENTION! Not the application admin, they may be different) must call the URL from the previous point (paste into browser and run), when a confirmation dialog will appear. After manual confirmation, the URL will change - its Code parameter contains the authentication string that you will then use when defining the gateway in FrontStage

https://fs5.apac-ancontact.com:5015/api/zalo?oa_id=4191244763757963092&code=kI_eroxY40scNFNlQSi5TPTroU5QvIbqs7Mvxsx04cF1F-gj3AyqGCCy-yW5ipPU_LFvyt75OrlMI_xKSheNFjypmEH1WJLgcGVz_4AI57J92uc6VwOzTeSKZCDcytGijcMjlXUxFNsDR9VxUPaULzyEXz5evayNqrIZxLN4Rdw3Ck2f6lTkQi8TheDxaJG9mchQy6UdHNw3JF3eLPTd9CKN-USStJzJgYV-d5A2GshkDAoUCD1rSSCqwh1NvbgstqVo2pl-Q_O6Fe0PlO5W-tKLh06IecQ6SWE_9EYXLhL-4DyFwhVUQGGH3xFwdQTl1YfPoFEhqIuUAJsNshN0T1HRJOVGzTLqVW9icQlmjcnx136J9gnssbqhc45g

Go to the “Webhooks” tab and set the “Webhook URL” to the same value as the verified address from step 5.The address must be different from the one set for “Callback URL” and must not contain a port!
After confirming the address, activate “Webhook events” (on the same page), which are of the form “user_send_xx” and “anonymous_send_yy”
You can now check that the setup and registration went well. Open the “Register to use the API” tab and check the “Official Account API” and “Social API” sections.

Important

During the development, the verification process at Zalo was still in some way under development and therefore changes from their side are possible in the future. The process described above is valid as of 05/2023

Creating Zalo gateway¶

Follow the gateway creation instructions , paying attention to the Device section when defining the gateway.

Possible form of Device for Zalo:

ServLinkZalo {
         "AppId": "XXXXXXXXXXXXXXXXX",
         "SecretKey": "XXXXXXXXXXXXXXX",
         "Code": "kI_eroxY40scNFNlQSi5TPTroU5QvIbqs7Mvxs...",
         "OA_ID": "123456789321",
         "InstantBannerMessages ": true,
         "MessagingApiUrl": "https://openapi.zalo.me/v3.0/oa/message/cs",
         "SocialApiUrl": "https://graph.zalo.me/v2.0/me",
         "TenantProxyVerificationToken": "GUID",
         "CodeVerifier":"GUID"
   }

Parameters:

AppId - you can find it on the tab “Settings” - step 4 when creating an account
SecretKey - you can find it on the Settings tab - step 4 when creating an account
Code - obtained in step 10 of account creation, needed for further message handling and replies
OA_ID - you can get it in step 7 of account creation, it is required to identify the incoming “GET request” (from Zalo side) when getting the Code
MessagingApiUrl - Currently used API URL for messages, optional parameter, if not filled the value in the example above is used as default
SocialApiUrl - Currently used API URL, optional parameter, if not filled the value in the example above is used as default
CodeVerifier - Verification token need for communication with developer application created under the Zalo account. GUID.

Configuring ServiceLink and social networks in the database¶

The behavior of the service is further influenced by the following parameters from the Configuration database table:

ServLinkSafeUris – comma (no space) separated list of safe domains. All URLs must come from one of these domains or they will be evaluated as potentially unsafe.
ServLinkTyntecBaseAddress – In case the address for calling services from Tyntec changes, it is possible to modify them via this parameter. This parameter is otherwise unnecessary, the address for Tyntec v2 is in the code. To activate V3, set this parameter to https://api.tyntec.com/conversations/v3
ServLinkThumbsUpIdList – Facebook is able to transfer up to 3 sizes of “inches”, this param contains their IDs, separated by semicolon (;) without spaces - thanks to these IDs ServiceLink recognizes them and is able to distinguish their sizes and transfer them to the chat
ServLinkSaveIncomingJsonData – indication, that the ServiceLink should save incomming messages as .txt files (JSON structure inside the file). If you can’t find the parameter in the administration, you should create it manually (it’s not a default FrontStage parameter, works only for the ServiceLink). Valid values are true and false. Files, that are created this way, serves the developers for “debugging” purpose only. They are not needed for daily operations and support purpose.

Note

Facebook posts images and files sent in a conversation to a public URL; therefore, ServiceLink does not download them and just links to them (this will be replaced by blob storage in the future). Images (.jpg, .png, .gif, etc) are embedded directly into <img> tags so that they appear directly to the agent in the conversation as images and not as links. The URLs of files and other attachments are always checked and the agent is then only shown whether the URL is safe or not. This depends on the SafeUris parameter.

Tyntec (WhatsApp) treats images the same way, but the exposed URLs are hidden behind ApiKey access. Therefore, using the Synchronous Service, it downloads and stores them in a short-term cache in RC (eventually this will also go to blob storage), where they are directly called up within the chat and displayed directly as an image. We do not support files/attachments for Tyntec (WhatsApp) for now.

Creating a gateway in general¶

In the Chat and ICR / Gateways section, create a gateway as follows:

The gateway name should be named as, for example, facebook chat because only by name it is possible later to identify in the chat the sources from which the message arrived.
Description can be a specification of what it is, for example the name of a Facebook page/url etc.
for Channel - this is an option for internal channel sorting, the groups do not bind any post-processing logic to each other. Recommended sorting:
- SocialIM - public social networks - WhatsUp, FB Messenger etc.
- BusinessIM - non-public social networks, internal Skype or MS Teams (in the future SMS in the form of chat)
- WebIM - WebSite - chats from sites
Direction is normally set as B (both), or I (incoming), or O (outgoing) – indicating who can start the conversation, then of course both can speak
Address - must match the address specified in the PeerAddress field in appsettings.json of the ServiceLink. If only one instance is deployed, !iCC.ServiceLink will be specified.
The Port is used to better identify the channel to avoid passing messages between channels to which they do not belong. For Facebook, the format “Facebook_<PageId>” is used, for WhatsApp (Tyntec) the phone number given in the JSON for Tyntec.
Device - detailed configuration of the specific service, including parameters, JSON format. Each object starts with the name of the service, with the prefix “ServLink”, for which the setting is - ServLinkFacebook, ServLinkWhatsApp, etc.

Important

ServiceLink updates the information from Device periodically (once every 2 minutes). If you need to update the content, just make the change and wait for the mentioned interval. There is no need to restart the service. Restarting is rather undesirable, because the service caches e.g. undelivered chats that it tries to deliver later and these would be lost at this point!
Momentum - the time after the end of a chat, when a reply or a new conversation with the same TrackingID does not create a new record in the Chat table, but reactivates the original chat and continues it
Inactivity - the time since the last message was sent, after which the chat is automatically closed (does not depend on the source of the message, i.e. both the agent and the customer are counted)
Reactivation for text replicas only - applies to both parameters above. If the option is active, the parameters apply only to text responses (the other side is a natural person). If the option is inactive, conversation recovery can also occur from technical channels (such as navigation). It is recommended to activate the option.
Source of contact identity - specifies which parameter can be stored (whispered) when working with DB.PhoneNumber - Values are “TechnicalAddress” for Facebook (PSID is stored) and “Numbers” for WhatsApp (phone number is stored)

Examples of individual JSON objects written to Device :

 ServLinkFacebook {
      "PageAccessToken": "XXXXXXXXXXXXXXXXX",
      "AppSecret": "XXXXXXXXXXXXXXX",
      "PageName": "Frontstage - TestPage",
      "PageId": "123456789321",
      "AppId": "987654321",
      "ApiVersion": "v10.0",
      "InstantBannerMessages ": true
}

 ServLinkWhatsApp {
     "ApiKey": "apiKeyApiKey",
     "PhoneNumber": "+420333451287"
      "InstantBannerMessages ": true
 }

Banner in chat¶

ServiceLink enables the BannerMessage capability, which depends on ChatGateCondition.Signal.

Depending on the values of Signal, BannerLiteralGroup and BannerCulture, the LL table is checked and then it contains the corresponding entry; the value of LL.DisplayName is sent as the first message.

Signal - The Signal value will then be used as the LiteralText value in the LL table.
BannerLiteralGroup - LiteralGroup for LL
BannerCulture - Specifies the preferred language for LL.
- For Signal = Free/Busy, the scenario is as follows: Message from customer -> automated BannerMessage -> customer response -> start of chat and connection with agent
- For values Signal = Closed/Hidden, BannerMessage is sent over and over again in response to each message from the customer, never creating a new chat.
- If the value of BannerLiteralGroup is NULL, BannerMessage is not applied and a new chat is always created.
- If BannerLiteralGroup is filled but BannerCulture is NULL, the preferred language/default (cs-CZ) is applied.
- If there is a missing entry in the LL table, BannerMessage is not applied and a new chat is always created.

Gateway JSON parameters¶

Each gateway supports detailed configuration for an external transmission system. The configuration is written to the Machine field, described above in Gate definition.

WhatsApp and Facebook¶

InstantBannerMessages - influences the default banner behavior, and it is controlled by the Signal parameter, configurable for Gateway conditions
- true - if the signal is Free/Busy, the banner is sent after the first message from the customer, and the chat starts (connection with the agent)
- false - the response to the first message is only a banner (no connection with the agent), and the second message from the customer leads to a connection with the agent
```
ServLinkWhatsApp
{
 "ApiKey": "f1DjwlFu3TM96ibPbepGbYRFgfzG1VZP",
 "PhoneNumber": "+420271004400",
 "InstantBannerMessages":true
}
```
Tip

It is useful to formulate the banner as a supplementary question.

Defining gateway and project Rules¶

When creating a gateway or project rule, you need to select the gateway that you have just created:

../../_images/fs-projektove-pravidlo.en.png

Logging of individual channels¶

For greater clarity, it is possible to enable logging for individual channels - Facebook, Tyntec, Zalo, and Yext support the Dbg parameter.

For example:

"Facebook": {
  "Url": "/api/facebook",
  "Active": false,
  "Dbg": false
}

In appsettings.json for ServiceLink, the Dbg parameter is set to false by default.

Parameter change options:

Directly in the appsettings.json - by changing it to true.

Using Lens (cloud)

{
  "name": "Facebook__Dbg",
  "value": "true"
}

Configuration using ReactAdmin - by changing the configuration parameter ServLinkDebugChannels.

Priority and settings system:

If ServLinkDebugChannels exists and contains “Facebook”, “Tyntec”, “Zalo”, “Yext” - set Dbg for the found channel to true
If ServLinkDebugChannels does not exist or does not contain any of the channels, the configuration is taken from appsettings.json
If the Dbg parameter for the channel is not present in appsettings.json, the Dbg is set to false