Chatbot Overview
Conversational Bots
Intents & Entities
Intelligent Bots
Kore.ai's Approach
Kore.ai Conversational Platform
Bot Concepts and Terminology
Natural Language Processing (NLP)
Bot Types
Bot Tasks
Starting with Kore.ai Platform
How to Access Bot Builder
Working with Kore.ai Bot Builder
Building your first Bot
Getting Started with Building Bots
Using the Dialog Builder Tool
Creating a Simple Bot
Release Notes
Latest Updates
Older Releases
Deprecations
Bot Builder
Creating a Bot
Design
Develop
Storyboard
Dialog Task
User Intent Node
Dialog Node
Entity Node
Supported Entity Types
Composite Entities
Supported Time Zones
Supported Colors
Supported Company Names
Form Node
Logic Node
Message Nodes
Confirmation Nodes
Service Node
Custom Authentication
2-way SSL for Service nodes
Script Node
Agent Transfer Node
WebHook Node
Grouping Nodes
Connections & Transitions
Managing Dialogs
User Prompts
Alert Tasks
Alert Tasks
Ignore Words and Field Memory
Digital Forms
Digital Views
Knowledge Graph
Terminology
Building
Generation
Importing and Exporting
Analysis
Knowledge Extraction
Small Talk
Action & Information Task
Action Tasks
Information Tasks
Establishing Flows
Natural Language
Overview
Machine Learning
ML Model
Fundamental Meaning
NLP Settings and Guidelines
Knowledge Graph Training
Traits
Ranking and Resolver
NLP Detection
Advanced NLP Configurations
Bot Intelligence
Overview
Context Management
Session and Context Variables
Context Object
Dialog Management
Sub-Intents
Amend Entity
Multi-Intent Detection
Sentiment Management
Tone Analysis
Sentiment Management
Default Conversations
Default Standard Responses
Channel Enablement
Test & Debug
Talk to Bot
Utterance Testing
Batch Testing
Record Conversations
Publishing your Bot
Analyzing your Bot
Overview
Dashboard
Custom Dashboard
Conversation Flows
Bot Metrics
Advanced Topics
Bot Authorization
Language Management
Collaborative Development
IVR Integration
Data Table
Universal Bots
Defining
Creating
Training
Customizing
Enabling Languages
Smart Bots
Defining
Sample Bots
Github
Asana
Travel Planning
Flight Search
Event Based Bot Actions
koreUtil Libraries
Bot Settings
Bot Functions
General Settings
PII Settings
Customizing Error Messages
Manage Sessions
Bot Management
Bot Versioning
Using Bot Variables
API Guide
API Overview
API List
API Collection
SDKs
SDK Overview
SDK Security
SDK App Registration
Web SDK Tutorial
Message Formatting and Templates
Mobile SDK Push Notification
Widget SDK Tutorial
Widget SDK – Message Formatting and Templates
Web Socket Connect & RTM
Using the BotKit SDK
Installing
Configuring
Events
Functions
BotKit SDK Tutorial – Agent Transfer
BotKit SDK Tutorial – Flight Search Sample Bot
Using an External NLP Engine
Bot Administration
Bots Admin Console
Dashboard
User Management
Managing Users
Managing Groups
Managing Role
Bots Management
Enrollment
Inviting Users
Bulk Invites
Importing Users
Synchronizing Users from AD
Security & Compliance
Using Single Sign-On
Security Settings
Cloud Connector
Analytics
Billing
How Tos
Creating a Simple Bot
Creating a Banking Bot
Transfer Funds Task
Update Balance Task
Context Switching
Using Traits
Schedule a Smart Alert
Configure Digital Forms
Add Form Data into Data Tables
Configuring Digital Views
Add Data to Data Tables
Update Data in Data Tables
Custom Dashboard
Custom Tags to filter Bot Metrics
Patterns for Intents & Entities
Build Knowledge Graph
Global Variables
Content Variables
Using Bot Functions
Configure Agent Transfer
  1. Home
  2. Docs
  3. Bots
  4. Bot Building
  5. Action & Info Task
  6. Action Tasks

Action Tasks

Starting Release 8.0.0, Action Tasks are no longer supported. This feature will be discontinued in the upcoming releases. We recommend using the Dialog Tasks and Digital Forms to build these use-cases

Action tasks allow Bot users to initiate and run a Bot task in third-party applications. They collect, modify, and post information in systems of record, eliminating repetitive, time-consuming steps or form-based data entry that customers and employees commonly perform.
Action tasks can acquire data from the user requests in one of two ways:

  • Long-Form Actions: User requests that include multiple entities or data fields in a single message, triggering the chatbot to extract the critical info and either collect only the missing information or immediately complete the task.
  • Guided Actions: User requests that state the high-level intent, thus forcing a series of bot-prompted questions for the user to provide additional field data necessary to complete the task.

Action tasks can be run independently or mapped as a follow-up task to another alert or action task.

Example Use Case: Assign a Jira Ticket

Let’s say you have a JIRA bot with an alert task that notifies you when new tickets get created. As a follow-up to the alert, you can an action tasks to that automatically that assigns the ticket to a specified agent. Action tasks are executed in third-party applications, which in this case is Atlassian JIRA.

Other Examples

These are a few other examples of Action tasks:

  • Create a new account with a brand
  • Become a loyalty program member
  • Search for a product
  • Schedule an appointment
  • Place a product order
  • Enter or report an issue
  • Escalate an issue

Configuring Action Tasks

Configuring an Action task involves the following settings:

General Settings

As the first step in building an Action task, you need to navigate to the Action Tasks tab in your bot and start creating one by entering the general details. The General tab for Action tasks includes details such as task name, connection mode, descriptions, and a few advanced settings such as its mapping to any other alert tasks.

  1. Open the bot in which you want to create the Action Task.
  2. Hover over the side navigation panel of the bot, and click Bot Tasks.
  3. On the Bot Tasks page, hover over the Action Task tab and click the plus icon.
  4. Enter a name for the task, which also doubles up as the display name. You can change the display name based on how you want the task to be named in the Kore.ai Bot Store.
  5. Select a connection mode for the task, Rest or SOAP, and then click Create & Proceed.
  6. The General Tab of the Action Task opens. Refer to the following table for the field descriptions.
Field Name Description
Display Name The name of the task as it gets displayed in the Kore.ai Bot Marketplace. It is the same as the task name unless you want to change it.
Task Name The name of the task as displayed everywhere in the application and end-user channels.
Connection Type The connection type for Action Tasks is always web service. The web service sends data to Kore.ai when it polls using the end user credentials. This setting is read-only for action tasks.
Connection Mode

This is the communications protocol connection type for your task as a web service. The web service sends data to Kore.ai when polled by Kore.ai using the end-user account login credentials.

  • REST – The task uses a REST API connection that is protocol-independent to exchange messages and to handle CRUD operations for web services.
  • SOAP – The task uses a SOAP API connection based on XML protocols for message exchange.
Long Description The long description of the action task.

Advanced Settings

You may want to configure optional advanced settings for your task. To expand the Advanced Settings section on the General tab, click the Expand rightarrowiconicon. The following table describes the Advanced Settings fields.

Field Name Description
Turn Off Confirmation Messages Select Yes to disable confirmation of the execution of a task when using NLP.
Mapped Only Action Task Select to only display this action task to an end-user if mapped from another task in a flow. When Yes is selected, the action task is not visible in an end-user search for action tasks.
Search Keywords Specify one or more search words an end-user can use to help locate this task in the Kore.ai Bot Store.
Task Demo Link Enter a www.youtube.com link to display a demo icon next to the task name in the Bot Store.
The following illustration shows a bot task defined with a Task Demo Link.
Authorization is required for Accessing the WSDL File
(Applies only to SOAP requests)
Select Yes to use authentication if web service authorization is required to access the WSDL for SOAP requests. When Yes is selected, the Authentication defined for the API request is used to access the WSDL. This setting is only available when the task Connection Mode is set to SOAP.
Get Optional Fields Select Yes to require the end-user to select and then enter at least one of the available optional parameters.
Ignore Words Enter one or more words to ignore for the task name, and then press enter after each word.
The list of words to ignore is processed by the Bots Platform before interpreting the user input. This means the Bot can respond faster to user input and provide the correct task by filtering out words that apply to many tasks but do not help to identify which task. For example, a user may input, I want to get the weather forecast for today. To return the correct action task to the user, the Bots Platform interpreter only needs to recognize three words, weather, forecast, and today. The rest of the words can be ignored.
The Kore.ai Bots interpreter is already defined with a set of generic ignore words, so words like I, you, want, get, etc., do not need to be defined as ignore words. If your Bot uses the same words for many or all tasks, for example, your company name, you might add your company name as an ignore word.
Error Messages Edit or add custom HTTP Status Codes and error messages for your Bot. For more information, see Customizing Error Messages.

Authorization

Depending on the Bot action task, you may need to define how a user must be authenticated to initiate the action task. For example, Twitter can have an action task using web services that require an end-user to authenticate, usually with a login username and password, to allow Kore.ai to access the end-user account for data before executing the action task.
You can define an Authorization profile or use an existing one. All authorization profiles, whether you create them at a task level or a bot level, can be used across all bot tasks.

  1. To get started with defining the Authorization for a task, from the API Request tab, click the Expand  icon in the Authorization section.
  2. If you have previously defined authentication for this task, you can select it in the Authorization Provider drop-down list.
  3. If your task does not require authentication, you can select None as the Authorization provider.
  4. To define a new authorization provider, click Create New to display the New Authorization Mechanism dialog.
  5. In the dialog, from the Authorization Type drop-down list, select the type of authorization used by your Bot. You can choose one of the following types of authorization:
    • Basic Auth – A standard protocol to collect username and password information. Kore.ai uses SSL encryption in combination with basic authentication to help secure end-user information. Click on the below link for the configuration details.

      Setting Up Authorization using Basic Auth

      The following illustration is an example of the Basic Auth fields that you must define to enable basic authorization for your task.To define basic authorization, select Basic Auth in the Authorization Type field. Then specify a Name for the authorization to be displayed in the Bot builder user interface.

      Defining Tenancy

      If required, in the Subdomain section, select Yes if the base URL for a web application or user interface the uses a tenant name in the URL. For example, kore is the tenant organization for a web service using tenants as www.kore.someCompany.com.
      In the following example configuration, the tenancy URL contains the {tenant} organization placeholder.

      Adding Form Fields

      If the default username and password fields do not meet your needs, you can add new fields displayed to the end-user by adding authorization form fields. To add fields on the authorization form, click + Add Form Field. The following illustration is an example of a definition to add a password field to the authorization dialog.

      The following table describes the fields used to define an authorization IDP form field.

      FIELD NAME DESCRIPTION
      Field Title Specify the name of the field displayed to the end-user in the authentication dialog.
      Field Key The value represents the end-user input value to the authenticating service.
      Help Hint The help text displayed in the field to describe what should be entered into the field.
      Field Type

      When Advanced Options is selected, specify the type of field displayed in the end-user interface to collect the user input assigned as the value for the Field Key, one of:

      • Textbox
      • Password
      Mandatory When Advanced Options is selected, select if the end-user must define this field to complete authentication.
      Data Type When Advanced Options is selected, specify the type of data expected as input from the end-user, for example, String.
      Visibility When Advanced Options is selected, specify if the authentication field should be visible, hidden, or displayed as read-only.
      Adding Authorization Fields

      By default, authorization fields are configured as part of the header of the task request message. If your task request requires additional authorization fields or the expected authorization is not part of the header, for example, social security number or PIN, click + Add Authorization Field and then define the fields as shown in the following illustration.

      In the Field Type field, you can select one of the following depending on where in the task request message and the type of authorization fields that are required.

      • Header – The Bot expects the authorization fields as part of the header of the request.
      • Payload – The Bot expects the authorization fields as part of the content of the body of the request.
      • Query String – The Bot expects the authorization fields as a query in the body of the request.
      • Path Param – The Bot expects the authorization fields as part of the URL path for the request.

      In the Field Key field, enter the name of the field for the selected Field Type.
      In the Field Value field, enter the value for the Field Key specified.
      Click Done. The new authorization field is added in the Authorization Fields section.
      To add additional authorization fields, click Add in the Authorization Fields section.
      In the Authorization Check URL field, optionally define a URL that can be used to test the authentication settings from Bot Builder before you deploy the task with the authorization mechanism. You can use dynamic fields, path parameter fields, query fields, and so forth, to define the test URL, for example,
      https://kore.someCompany.com/sap/opu/odata/sap/{{authfield1}}/?$format=json
      In the Access Using a Connector section, select Yes to enable access for Kore.ai Bots using the Kore.ai Connector agent. If your domain does not have any active Kore.ai Connectors defined, a warning message is displayed to contact the Bots Admin Console system administrator. For more information, see Using the Kore.ai Connector in the Bots Admin Console documentation.
      Click Save to save the authorization settings and close the New Authorization Mechanism dialog.

      Testing the Authorization – Basic Auth

      After you save the authentication, if you defined an Authorization Check URL for your new authorization type, you can test your authorization definition on the Authorization tab when you click Test Authorization before continuing to develop the remaining steps of your task.
      Test Authorization
      When you click Test Authorization, the Test Authorization dialog is displayed and populated with the URL you specified in the Authorization Check URL section, as shown in the following illustration.

      To configure the Test Authorization – Basic Auth

      1. In the Auth Check URL field, verify or enter the URL to test the authentication configuration.
      2. If your bot uses subdomains, the Tenancy field is displayed and you must specify the tenant.
      3. Enter your User Name and Password for the web service.
      4. Select the content type expected for the URL in the Content-Type field.
      5. For testing the URL, the Method field is read-only and set to GET.
      6. Click Test to begin the authorization test.

      When the validation of authentication is complete, the Test Authorization dialog is closed and the results of the validation, either success or failure, is displayed to the immediate right of the Test Authorization button as shown in the following illustration.
      Test Authentication - Success
      If the authorization fails, the Auth Test Failed message is displayed along with the Headers and Response tabs as shown in the following illustration.
      Authentication Test Fail

      How it all Works – Basic Auth

      When basic authorization is used for a task, the Kore.ai application automatically prompts the user for log in credentials to access the web application or web service as shown in the following illustration.
      DIYBasicAuthRequest
      After the end-user is authorized, the settings are saved using the following naming syntax:

      {{ First Name }} {{ Last Name }} {{ Bot Name }} {{ Account # }} {{ Sequence # }}

      For example, John Smith’s Twitter Account #1.
      The Kore.ai application can access the web application or web service for all future task requests using this account. In addition, the end-user can reuse the account for other tasks for the same Bot.

    • OAuth v2 password grant type – Define a custom authorization type for non-standard web service authorization types. Click on the link below for the configuration details.

      Setting Up Authorization using oAuth v2 password grant

      The following illustration is an example of the oAuth v2 password grant authorization type fields that you must define to enable a customized authorization for your task.New Authorization Mechanism Dialog - oAuth v2 password grantTo define a custom authorization, select oAuth v2 password grant in the Authorization Type field. Then specify a Name for the authorization to be displayed in the Bot builder user interface.

      Defining Tenancy

      If required, in the Subdomain section, select Yes if the base URL for a web application or user interface the uses a tenant name in the URL. For example, kore is the tenant organization for a web service using tenants as www.kore.someCompany.com.
      In the following example configuration, the tenancy URL contains the {tenant} organization placeholder.

      Adding Form Fields

      If the default username and password fields do not meet your needs, you can add new fields displayed to the end-user by adding authorization form fields. To add fields on the authorization form, click + Add Form Field. The following illustration is an example of a definition to add a password field to the authorization dialog.

      The following table describes the fields used to define an authorization IDP form field.

      FIELD NAME DESCRIPTION
      Field Title Specify the name of the field displayed to the end-user in the authentication dialog.
      Field Key The value represents the end-user input value to the authenticating service.
      Help Hint The help text displayed in the field to describe what should be entered into the field.
      Field Type

      When Advanced Options is selected, specify the type of field displayed in the end-user interface to collect the user input assigned as the value for the Field Key, one of:

      • Textbox
      • Password
      Mandatory When Advanced Options is selected, select if the end-user must define this field to complete authentication.
      Data Type When Advanced Options is selected, specify the type of data expected as input from the end-user, for example, String.
      Visibility When Advanced Options is selected, specify if the authentication field should be visible, hidden, or displayed as read-only.
      Adding Authorization Fields

      By default, authorization fields are configured as part of the header of the task request message. If your task request requires additional authorization fields or the expected authorization is not part of the header, for example, social security number or PIN, click + Add Authorization Field and then define the fields as shown in the following illustration.

      In the Field Type field, you can select one of the following depending on where in the task request message and the type of authorization fields that are required.

      • Header – The Bot expects the authorization fields as part of the header of the request.
      • Payload – The Bot expects the authorization fields as part of the content of the body of the request.
      • Query String – The Bot expects the authorization fields as a query in the body of the request.
      • Path Param – The Bot expects the authorization fields as part of the URL path for the request.

      In the Field Key field, enter the name of the field for the selected Field Type.
      In the Field Value field, enter the value for the Field Key specified.
      Click Done. The new authorization field is added in the Authorization Fields section.
      To add additional authorization fields, click Add in the Authorization Fields section.

      Defining the Token URL

      In the Token URL field, optionally define a URL that can be used to test the authentication settings from Bot Builder before you deploy the task with the authorization mechanism. You can use dynamic fields, path parameter fields, query fields, and so forth, to define the test URL, for example,
      http://{tenant}.someCompany.com/test/{{tokenId}}
      In the Token URL Method field, select the HTTP request method type for the Token URL. One of PUT, POST, PATCH, DELETE, and GET.
      In the Token URL Content Type field, select the content type expected from the Token URL. One of: JSON, RSS, XML, URL Encoded JSON, CSV, Text, Twitter Encoded JSON, Multipart/Form-data,Multipart/Related, or Oracle ADF.
      In the Access Using a Connector section, select Yes to enable access for Kore.ai Bots using the Kore.ai Connector agent. If your domain does not have any active Kore.ai Connectors defined, a warning message is displayed to contact the Bots Admin Console system administrator. For more information, see Using the Kore.ai Connector in the Bots Admin Console documentation.
      Click Save Auth to save the authorization settings and close the New Authorization Mechanism dialog.

      Testing the Authorization

      After you save the authentication, if you defined an Authorization URL for your new authorization type, you can test your authorization definition on the Authorization page when you click Test Authorization before continuing to develop the remain steps of your task.
      Test Authorization
      When you click Test Authorization, the Test Authorization dialog is displayed and populated with the URL you specified in the Authorization Check URL section, as shown in the following illustration.
      Test Authorization Dialog - OAuth V2 Password Grant
      Click Test to begin the authorization test. When the validation of authentication is complete, the Test Authorization dialog is closed and the results of the validation, either success or failure, is displayed to the immediate right of the Test Authorization button. If the authorization fails, the Auth Test Failed message is displayed along with the Headers and Response tabs as shown in the following illustration.
      Authentication Test Fail

    • OAuth v2 client credential
    • OAuth v1 – Enables web applications or web services to access protected resources using an API without end-users having to disclose their log on credentials to Kore.ai. Click on the link below for the configuration details.

      Setting Up Authorization using OAuth v1

      OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications.To use OAuth, you must first register an account with the web application as you will need the log in credentials for that application to configure the settings for the authorization mechanism.

      How OAuth v1 Works
      1. The Kore.ai application obtains an unauthorized request token from the web application. The Kore.ai application redirects the user to a login dialog at the web application.
      2. The user authorizes the request token, associating it with their account. The web application redirects the user back to the Kore.ai application.
      3. The Kore.ai application exchanges the request token for an access token.
      4. The access token allows the Kore.ai application to access a protected resource at the provider, on behalf of the user.

      The following illustration is an example of the oAuth v1 authorization type fields that you must define to enable a customized authorization for your task.
      New Authorization Mechanism - oAuth V1
      To define oAuth v1, define the fields described in the following table.

      FIELD NAME DESCRIPTION
      Authorization Type Set to oAuth v1.
      Callback URL The URL used by the web application or web service to redirect the end-user after end-user authorization is complete. This value, https://idp.kore.ai/workflows/callback/,  is provided as a read-only value by the Kore.ai application when you define oAuth v1 settings.
      Identity Provider Name The name of the web application or web service, for example, Twitter. This field is required.
      Consumer Key The value provided as the Kore.ai application identification to the web application. This field is required.
      Consumer Secret The secret value provided by the Kore.ai application to establish ownership of the Consumer Key. This field is required.
      Request Token Link The URL used by the Kore.ai application to obtain an unauthorized request token. A request token is the value used by the Kore.ai application to obtain authorization from the end-user to obtain an access token. For example, https://{tenant}.someCompany.com/oauth/request_token. After end-user authorization, an access token can be requested by the Kore.ai application. This field is required.
      Access Token Link The URL used to exchange the end-user authorized request token for an access token. The access token is the value used by the Kore.ai application to gain access to the web application or web service on behalf of the end-user, instead of using the end-users log on credentials. For example, https://{tenant}.someCompany.com/oauth/access_token. This field is required.
      User Authorization Link The URL used to obtain end-user authorization for the Kore.ai application to access the web application or web service using the access token. For example, https://{tenant}.someCompany.com/oauth/authorize. This field is required.
      Access Using a Connector Select Yes to enable access for Kore.ai Bots using the Kore.ai Connector agent. This option is only visible if a Kore.ai Connector agent is configured and enabled in your enterprise on-premises network. For more information, see Using the Kore.ai Connector.

      Defining Tenancy

      If required, in the Subdomain section, select Yes if the base URL for a web application or user interface the uses a tenant name in the URL. For example, kore is the tenant organization for a web service using tenants as www.kore.someCompany.com.
      In the following example configuration, the tenancy URL contains the {tenant} organization placeholder.

      Adding Additional Fields

      Click + Add Additional Fields to open the Additional Fields dialog, and then enter one or more key/value pairs that represent additional authorization input fields if required as shown in the following illustration.
      Additional Authorization Fields
      Specify the following fields:

      • Field Key – The name of the custom field to specify for authorization.
      • Field Value – The value of the custom field to specify for the authorization.

      Click Add to save the Additional Field.
      To add more Additional Fields, click Add in the Additional Fields section.

      Adding Authorization Fields

      By default, authorization fields are configured as part of the header of the task request message. If your task request requires additional authorization fields or the expected authorization is not part of the header, for example, social security number or PIN, click + Add Authorization Field and then define the fields as shown in the following illustration.
      Authorization Fields for Basic Auth
      In the Field Type field, you can select one of the following depending on where in the task request message and the type of authorization fields that are required.

      • Header – The Bot expects the authorization fields as part of the header of the request.
      • Payload – The Bot expects the authorization fields as part of the content of the body of the request.
      • Query String – The Bot expects the authorization fields as a query in the body of the request.
      • Path Param – The Bot expects the authorization fields as part of the URL path for the request.

      In the Field Key field, enter the name of the field for the selected Field Type.
      In the Field Value field, enter the value for the Field Key specified.
      Click Add. The new authorization field is added in the Authorization Fields section.
      To add additional authorization fields, click Add in the Authorization Fields section.

      Testing the Authorization

      After you save the authorization, you can test your authorization definition on the Authorization page when you click Test Authorization before continuing to develop the remain steps of your task.
      Test Authorization
      When you click Test Authorization, the test is executed using the authentication token URLs and the Consumer Key and Consumer Token. If the tenancy was defined, the Test Authorization dialog is displayed as shown in the following illustration.
      Test Authorization Dialog - oAuth
      Click Test to begin the authorization test. When the validation of authentication is complete, the Test Authorization dialog is closed and the results of the validation, either success or failure, is displayed to the immediate right of the Test Authorization button. If the authorization fails, the Auth Test Failed message is displayed along with the Headers and Response tabs as shown in the following illustration.
      Authentication Test Fail

    • OAuth v2 – The newest version of OAuth protocol focusing on specific authorization flows for web applications and web services. Click on the link below for the configuration details.

      Setting Up Authorization using OAuth v2

      OAuth v2 is the new version of the open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications.To use oAuth v2, you must first register an account with the web application as you will need the log in credentials for that application to configure the settings for the Authorization Mechanism.

      How oAuth v2 Works

      1. The Kore.ai application redirects the user to a login dialog at the web application.
      2. The user authenticates.
      3. The web application redirects the user back to the Kore.ai application with an access token.
      4. The Kore.ai application validates the access token.
      5. The access token allows the Kore.ai application to access a protected resource at the provider, on behalf of the user.

      The following illustration shows the fields to define for the oAuth v2 Authorization Type.
      oAuth v2 Dialog
      To configure oAuth v2, define the fields described in the following table.

      FIELD NAME DESCRIPTION
      Authorization Type Set to oAuth v2.
      Callback URL The URL used by the web application or web service to redirect the end-user after end-user authorization is complete. This value, https://idp.kore.ai/workflows/callback/ is provided as a read-only value by the Kore.ai application when you define oAuth v2 settings.
      Identity Provider Name The name of the web application or web service, for example, Asana. This field is required.
      Client ID The ID of the Kore.ai client.
      Client Secret Key The value provided as the Kore.ai application authentication based on the Client ID to the web application.
      Authorization URL The URL used to obtain end-user authorization for the Kore.ai application to access the web application or web service using the access token. This field is required.
      Access Using a Connector Select Yes to enable access for Kore.ai Bots using the Kore.ai Connector agent. This option is only visible if a Kore.ai Connector agent is configured and enabled in your enterprise on-premises network. For more information, see Using the Kore.ai Connector.
      Authorization URL The URL used by the Kore.ai application to obtain an unauthorized request token. A request token is a value used by the Kore.ai application to obtain authorization from the end-user to obtain an access token. After end-user authorization, an access token can be requested by the Kore.ai application. This field is required.

      Defining Tenancy

      If required, in the Subdomain section, select Yes if the base URL for a web application or user interface the uses a tenant name in the URL. For example, kore is the tenant organization for a web service using tenants as www.kore.someCompany.com.
      In the following example configuration, the tenancy URL contains the {tenant} organization placeholder.
      Task Subdomain Section

      Adding Additional Fields

      Click + Add Additional Fields to open the Additional Fields dialog, and then enter one or more key/value pairs that represent additional authorization input fields if required as shown in the following illustration.
      Additional Authorization Fields
      Specify the following fields:

      • Field Key – The name of the custom field to specify for authorization.
      • Value – The value of the custom field to specify for the authorization.

      Click Add to save the Additional Field.
      To add more Additional Fields, click Add in the Additional Fields section.

      Adding Authorization Fields

      By default, authorization fields are configured as part of the header of the task request message. If your task request requires additional authorization fields or the expected authorization is not part of the header, for example, social security number or PIN, click + Add Authorization Field and then define the fields as shown in the following illustration.
      Authorization Fields for Basic Auth
      In the Field Type field, you can select one of the following depending on where in the task request message and the type of authorization fields that are required.

      • Header – The Bot expects the authorization fields as part of the header of the request.
      • Payload – The Bot expects the authorization fields as part of the content of the body of the request.
      • Query String – The Bot expects the authorization fields as a query in the body of the request.
      • Path Param – The Bot expects the authorization fields as part of the URL path for the request.

      In the Field Key field, enter the name of the field for the selected Field Type.
      In the Field Value field, enter the value for the Field Key specified.
      Click Add. The new authorization field is added in the Authorization Fields section.
      To add additional authorization fields, click Add in the Authorization Fields section.

      Testing the Authorization

      After you save the authorization, you can test your authorization definition on the Authorization page when you click Test Authorization before continuing to develop the remain steps of your task.
      Test Authorization
      When you click Test Authorization, the test is executed using the authentication token URLs and the Client ID and Client Secret Key. If the tenancy was defined, the Test Authorization dialog is displayed as shown in the following illustration.

      Click Test to begin the authorization test. When the validation of authentication is complete, the Test Authorization dialog is closed and the results of the validation, either success or failure, is displayed to the immediate right of the Test Authorization button. If the authorization fails, the Auth Test Failed message is displayed along with the Headers and Response tabs as shown in the following illustration.

    • API Key – An identification and authorization token generated or provided by a web application or web service used to identify the incoming application request, and in some cases, also provide authentication for secure access. Click on the link below for the configuration details.

      Setting Up Authorization using an API Key”

      An API key can act as both a unique identifier and a secret token for identification as well as authentication to provide a set of access rights on the associated API. Instead of prompting the end-user for both a username and password for access, the user is prompted only for an API key when configuring the task.To use the API Key Authorization Type, you must first register an account with the web application and then generate an API Key for that application to configure the settings for the Kore.ai authorization mechanism.The following illustration shows the fields to define for the API Key Authorization Type.Authorization Tab - API Key DialogTo define an API key authorization, select API Key in the Authorization Type field. Then specify a Name for the authorization to be displayed in the Bot builder user interface.

      Defining Tenancy

      If required, in the Subdomain section, select Yes if the base URL for a web application or user interface the uses a tenant name in the URL. For example, kore is the tenant organization for a web service using tenants as www.kore.someCompany.com.
      In the following example configuration, the tenancy URL contains the {tenant} organization placeholder.

      Adding Form Fields to the Authorization Form

      If the default username and password fields do not meet your needs, you can add new fields displayed to the end-user by adding authorization form fields. To add fields on the authorization form, click + Add Form Field. The following illustration is an example of a definition to add a password field to the authorization dialog.

      The following table describes the fields used to define an authorization IDP form field.

      FIELD NAME DESCRIPTION
      Title of Field Specify the name of the field displayed to the end-user in the authentication dialog.
      Field Key The value represents the end-user input value to the authenticating service.
      Help Hint The help text displayed in the field to describe what should be entered into the field.
      Field Type

      When Advanced Options is selected, specify the type of field displayed in the end-user interface to collect the user input assigned as the value for the Field Key, one of:

      • Textbox
      • Password
      Mandatory When Advanced Options is selected, select if the end-user must define this field to complete authentication.
      Data Type When Advanced Options is selected, specify the type of data expected as input from the end-user, for example, String.
      Visibility When Advanced Options is selected, specify if the authentication field should be visible, hidden, or displayed as read-only.

      Adding Authorization Fields

      By default, authorization fields are configured as part of the header of the task request message. If your task request requires additional authorization fields or the expected authorization is not part of the header, for example, social security number or PIN, click + Add Authorization Field and then define the fields as shown in the following illustration.

      In the Field Type field, you can select one of the following depending on where in the task request message and the type of authorization fields that are required.

      • Header – The Bot expects the authorization fields as part of the header of the request.
      • Payload – The Bot expects the authorization fields as part of the content of the body of the request.
      • Query String – The Bot expects the authorization fields as a query in the body of the request.
      • Path Param – The Bot expects the authorization fields as part of the URL path for the request.

      In the Field Key field, enter the name of the field for the selected Field Type.
      In the Field Value field, enter the value for the Field Key specified.
      Click Add. The new authorization field is added in the Authorization Fields section.
      To add additional authorization fields, click Add in the Authorization Fields section.

      Testing the Authorization – API Key

      After you save the authentication, if you defined an Authorization Check URL for your new authorization type, you can test your authorization definition on the Authentication tab when you click Test Authorization before continuing to develop the remain steps of your task.
      Test Authorization
      When you click Test Authorization, the Test Authorization dialog is displayed and populated with the URL you specified in the Authorization Check URL section, as shown in the following illustration.
      Test Authorization - API Key
      To configure the Test Authorization – API Key

      1. In the Auth Check URL field, verify or enter the URL to test the authentication configuration.
      2. If your bot uses subdomains, the Tenancy field is displayed and you must specify the tenant.
      3. Enter the API key for the application in the API Key field.
      4. Select the content type expected for the URL in the Content-Type field.
      5. For testing the URL, the Method field is read-only and set to GET.
      6. Click Test to begin the authorization test.

      When the validation of authentication is complete, the Test Authorization dialog is closed and the results of the validation, either success or failure, is displayed to the immediate right of the Test Authorization button. If the authorization fails, the Auth Test Failed message is displayed along with the Headers and Response tabs as shown in the following illustration.
      Authentication Test Fail

API Request

The alert task request object gets data for the notification message displayed to the end-user. The configuration settings for a request object are based on the Connection Type that you define for the Alert task request object. For more information, see one of the following:

API Request - Rest

API Request - SOAP

Bot Response

Version History for Action Tasks

View Logs for Action Tasks

Menu