Configure Request-based chats to import messages from Microsoft Teams to ServiceNow
Configure request-based chats for IT Service Management integration with Microsoft Teams and HR Service Delivery integration with Microsoft Teams applications enable the system to auto import the chat conversations between the agents and the employees.
- HR Core task (sn_hr_core_task)
- HR Life events Case (sn_hr_le_case)
- HR Core case (sn_hr_core_case)
- Request Item (sc_req_item)
- Task (sc_task)
- Incident (incident)
- Request (sc_request)
- Change request (change_request)
The admin can extend the auto import feature to the other tables as required. For more information see, Create requester mapping.
If you are upgrading your ServiceNow instance to IT Service Management integration with Microsoft Teams 2.2.0 or HR Service Delivery integration with Microsoft Teams 2.2.0, you must manually enable the auto import feature.
Functionality of auto importing messages
All the chat messages from Microsoft Teams will be auto imported to the ServiceNow instance at an interval of 30 minutes. The system looks for all the new messages across all the chats and import the messages to ServiceNow instance.
To prevent polling from running indefinitely on inactive conversations, if there are no new messages, the polling interval will gradually lengthen until, eventually, polling stops.
The system verifies the record for new messages for every 30 minutes. If there are no new messages, the system checks for the new messages for an interval of one hour, two hour, four hour and eight hours. If there are no new messages in an interval of eight hours for seven days, the Auto Import polling activity is disabled.
If there is any message during any of the intervals, the auto import timer will look for the new messages in the next interval, and import the messages. The timer is then reset to 30-minutes interval.
System Limits
The system imports a maximum of 500 active chats in a 30-minute interval. If there are more than active 500 chats the system will not auto-import the new chat records for the 30-minute interval.
The system executes a maximum of 10,000 sub-flows to import the chats for an interval of 30 minutes, 1 hour, 2 hour, 4-hour, 8-hour intervals. This is a count of all the active subflows that auto-import the messages into ServiceNow.
If the system reaches the limit, a message is displayed to the agent that the system level is reached and the chat can’t be auto imported on the Start Microsoft Teams Chat modal.
When the ticket is closed, the system will trigger auto import for one last time posts the new messages in the Work notes (Chat history).
If there is an interaction record associated with the parent record then interaction record is also closed. The chat record will also be closed as part of this flow.
If you want to continue using the default configuration, you can skip the following procedures to extend the auto-import functionality. However, if you want to extend the auto-import functionality to other tables, perform the steps mentioned in the topics below.
Configure the chat to enable auto-import
Create a chat configuration to automatically import the chats between the agents and the requesters for additional tables to extend the auto import functionality.
Before you begin
Role required: admin
Procedure
Create requester mapping
Create a requester mapping to extend the auto-import functionality to other tables.
Before you begin
Role required: admin
If there is no requestor mapping defined for a table, the interaction records will not be created. An error log is created for the admin to notify that the requestor mapping is not defined for a table.
A requestor-mapping record defines which field, in any given table, is the field representing the requestor of a ticket.
Procedure
Configure close condition
Configure the condition to exclude the chat conversation from auto importing.
Before you begin
Role required: admin
About this task
When a ticket is set to inactive, the system does one final poll for any messages in the chat, removes the participants such that no further messages about the ticket can be exchanged in the chat, and then stops polling that chat. This is determined by the "active" field on a table being set to "false".
For any table with an active field, this behavior works automatically. If your custom application does not use an "active" field for determining whether the ticket remains active, define an alternate condition that can be used to denote the ticket as being closed or inactive.
Alternately, to adhere to platform standards, consider adding an active field to your custom application and maintaining the state of that field in accordance with the business logic of your application.
If you are creating a close condition for a new table, ensure to create business rule for close condition. For more information, see Configure business rule for close condition.