Configurable Chat History

Configurable chat history allows SMEs to configure the date range for visible chat history on a user’s chat user interface. The selected date limit restricts visible chat history.

With the help of this feature, users can basically customize from the cognitive console the number of days of chat history that they want to be displayed to the end user.

This section covers how to customize the chat history for the tenant and contains all the messages that should appear, all the steps that should be taken in the process, and the validations required.

Go to the Master Configuration Console from the BigFix AEX Cognitive Console.

Look for the Data Security tab.
Click on the Edit icon on the right side of the Data Security tab.

Figure 1. Figure 33 – Master Configuration Console - Data Security Tab

The following screen appears:
Figure 2. Figure 34 – Data Security
1. Change the entry in the Chat History Duration field. It takes numbers between 1 and 180, i.e., your chat history records could be configured between data from 1 day to data from 180 days. You can select any number in between.
Figure 3. Figure 35 – Chat History Duration
As soon as the duration is specified in the Chat History Duration field, the save icon appears on the top right of the screen.
1. Click on the save icon to save the changes. To cancel the action, click on the close icon.

Clicking on save icon displays a confirmation message as follows:
Figure 4. Figure 36 – Confirmation Message
1. Click OK to confirm the action and click Cancel to cancel it. The following success message appears if the action is confirmed by clicking OK:
Figure 5. Figure 37 – Success Message
1. Click OK. The end users will now be able to view the chat history for the specified duration.
Figure 6. Figure 38 – Chat History for the Specified Duration

One Click Connectors Openwhisk Ruless
BigFix AEX comes out-of-box with the following integrations:

GET_SOP
- This Integration allows BigFix AEX to display the Standard Operating Procedure (SOP) HTML to the user in the chat UI. It takes as input the SOP ID that was generated when the SOP was created from the SOP Management console. For more details on using the SOP Management module, please refer to the corresponding section in the BigFix AEX Configuration Guide.
You can call this integration from the dialog node of Watson Assistant by putting the following statement in the Text Response: _API_RULE_;GET_SOP;{"sop_id":"ID OF THE SOP DOCUMENT"};{}

_RES_CONFIRM_RESOLUTION_

This Integration allows BigFix AEX to display a short form to the user to get the feedback on whether the user was able to get the resolution on his/her question. This integration can be called from the dialog node of Watson Assistant by putting the following statement in the Text Response: _RES_CONFIRM_RESOLUTION_

_RES_FEEDBACK_FORM_

This integration allows BigFix AEX to display short form-based feedback capturing flow to get the satisfaction of users with respect to each use case. This is different from _RES_CONFIRM_RESOLUTION_ where the feedback on whether user got the resolution or not.

Text Response: _RES_FEEDBACK_FROM_

PERSONALITY

This Integration allows BigFix AEX to display some of the pre-trained personality responses like greetings, weather, news, etc. to the user in the chat UI. It takes the User Query as input which is not essentially a use case trained in BigFix AEX. PERSONALITY comes added with any new deployment of BigFix AEX tenant and can be used by calling the integration with the integration ID PERSONALITY.

You can call this integration from the dialog node of Watson Assistant by putting the following statement in the Text response: _API_RULE_; PERSONALITY;{};{}

This module in BigFix AEX is automatically deployed for every tenant that is created. This comes with extensively trained set of personality responses with over 400 questions and along with it easy to read cards like Weather or news.

Features

Over 400 responses and updates
Provides configurable bot names on response
Has multi-lingual capabilities on the fast train
Supports other computational intelligence systems like WolframAlpha
Supports query re-routing to Search engines like Google
Behaves as a filter for pre-search mechanism
Highly modularized and configurable service flows
Registers unanswered queries
Channel-based response formatting

Usage

Adding an API RULE on anything_else node on Watson of the name “PERSONALITY” should work by itself. All deployed tenants come with the flow already registered with this RULE.

Additionally, Personality Integration module provides multiple configurable parameters as follows:

Table 1. Table 4  Multiple configurable parameters for Personality Integration Module
Parameter Name	Description	Default value
bot_name	It is used if the Bot name needs to be changed from “BigFix AEX” to some other name.	“BigFix AEX”
disable_wolfram	It disables WolframAlpha redirection if the trained personality did not respond.	False
on_wolfram_different_response	It disables cards.	False
allow_single_word	Used as a filter to not allow single word queries propagate to additional search integrations, if any.	True
on_single_word_message	Message to respond if user sent single word	“”
fallback_message	This is the fallback message when nothing was identified.	“I’m unable to understand, could you rephrase your query.”
fallback_options	This provides option buttons with fallback message	[]
google_enabled	Allow to perform Google search, if no response from Personality trained data	False
on_card_disable	Response to throw if cards were identified by personality but it was disabled by on_wolfram_different_response	“Card based response are disabled”

Personality Rule also supports RULE engine-based profile parameters.

By default, Personality Integration has context and other information which it can use to provide more context-based responses. One of them is “lang”. If this context is set, then the user can trigger the response in the respective language. The values for “lang” is consistent with the multilingual representation on the main Watson flow.

Depending on the channel, the Personality also changes its response format to be compatible with the channel’s experience. Similarly, Teams also gets a different view of the card-based personality responses. This is again recognized by the context passed to Personality by default.

Best Practices

Always call the API RULE on the Watson over Anything_else
If you want to generate random response for fallback, then use the API RULE on the same Node with random response type on Watson and on each define different fallback_message
If you are using multilingual, then a fallback message can be written on different condition on the respective language using the same method as previous.
Avoid enforcing or changing “lang” when on multilingual and let BigFix AEX handle the language transition automatically
If using searching integrations, better to call Personality before the actual search.

GET_SOP and PERSONALITY are inbuilt integrations so the integration id GET_SOP and PERSONALITY should be avoided when new integrations are created. Creating an integration with the above-mentioned id will not be valid as the system will give preference to inbuilt integrations ignoring the integrations created by users with the same id.

URL Parameters.

URL query parameters can be used in BigFix AEX for context and understanding, or to drive the integration. A parameter with value can be passed to BigFix AEX from the Instance URL query parameters for Web Client of BigFix AEX which can be used in the Dialog flow or for Integrations.

Example:

URL: <INSTANCE URL>/?ticket_number=REQ0001234

The above example can let you consume the ticket_number in the watson dialog flow design and integrations. Any query parameter added to the URL will be added to context of the ongoing conversation which can be accessed in Watson and in the Integration module under parameters (params).