Streamline employee support with Amazon Connect and Microsoft Teams integration

Overview

Many large enterprises struggle with IT support inefficiencies where service desks are overwhelmed by high volumes of basic requests that employees could resolve through self-service options. This creates longer wait times for employees and prevents IT staff from focusing on complex technical issues.

A leading international financial services organization, with $1.46 trillion in assets under management and over 20,000 employees, faced this exact challenge. As part of their cloud-first digital transformation strategy, they selected AWS as their strategic technology provider to drive innovation and modernize client experiences. The organization implemented Amazon Connect as their Contact Center as a Service (CCaaS) solution to transform their contact center operations and deliver more engaging support experiences.

Use case

As a large enterprise with over 20,000 employees, the organization’s service desk received high volumes of IT support requests, with many employees calling with basic issues they could potentially resolve themselves. This created long wait times for employees and prevented IT staff from focusing on complex technical issues.

To optimize their IT support model, the organization implemented a multi-channel solution. They deployed an AI-powered chatbot using Amazon Connect that provides automated responses to common IT queries, direct access to knowledge base articles, and intelligent escalation to human agents when needed.

As part of a pilot program, they integrated the chatbot with Microsoft Teams to meet employees where they work. This embedded support capabilities directly in the Teams interface, enabling seamless chat interactions without leaving the Teams environment and providing consistent experience across web portal and Teams platforms.

The solution uses the Amazon Connect chat for easy integration with both the employee portal and Microsoft Teams, making self-service support more accessible for employees.

This post walks through how the organization integrated Amazon Connect omnichannel routing capabilities with a customized Microsoft Teams chatbot. You’ll understand how the technologies work together to create engaging chat interactions and have an enterprise blueprint demonstrating the integration.

Prerequisites

The solution discussed in this blog requires working knowledge of following AWS services:

Amazon API Gateway
AWS Lambda
Amazon DynamoDB
Amazon Simple Notification Service (SNS)
Amazon Connect and Amazon Connect Contact Control Panel flow (CCP flow)
Amazon Lex

You will need to setup Azure Bot in your Azure account and deploy an application in Microsoft Teams developer portal. Azure bot integrates with Microsoft Teams and acts as an interface between Teams and Amazon API Gateway. Refer to GitHub repository for detailed steps.

Additionally, to deploy the solution, you should be familiar with Terraform (by HashiCorp) scripts and Unix shell script.

Solution architecture

Figure 1: Amazon Connect & Microsoft Teams Integration architecture

You’ll deploy a Microsoft 365 app to your company’s Teams store to enable Teams-Amazon Connect communication via Azure Bot Service. When users send messages in Teams, Azure Bot Service forwards them through API Gateway to a Lambda function, which initiates an Amazon Connect chat session and stores user metadata in DynamoDB.

The Connect Contact Control Panel (CCP) flow integrates with Amazon Lex for chatbot responses. When responses are generated (either from the flow or live agents), they’re sent to an SNS topic, triggering another Lambda function that retrieves the Teams metadata and delivers the response to the appropriate Teams user.

This solution implements private chat functionality in Teams but can be extended for group conversations. Sample code and detailed implementation steps are available on GitHub.

Solution walkthrough

This walkthrough describes how user’s chat requests are handled in the solution, and how the user receives responses in Microsoft Teams from Amazon Connect. The chat flow is separated into two parts. Step 1 to Step 4 includes how Microsoft Teams user initiates a chat connection with Amazon Connect. Step 5 to 9 describes how the user receives a response from Amazon Connect in Teams.

1. User must load the “Teams” application configured to talk to Amazon API Gateway. Refer to GitHub to setup and install Teams app in your Microsoft 365 account and Azure Tenant.
a. User types a message in the Teams App.
b. The message is routed to Azure Bot Service, which then invokes Amazon API Gateway REST API endpoint.
c. Amazon API Gateway invokes a Lambda Proxy function configured to handle the incoming REST API request. Note, before invoking Lambda Proxy function, Amazon API Gateway can invoke an API Authorizer to ensure the request comes from Microsoft Azure Bot Service with proper credentials. Refer to accompanying GitHub for further details.
d. Lambda function uses Microsoft BotBuilder Framework for Python to process the incoming Teams message. As part of this call, Lambda extracts Teams user’s id (who is sending the message), Teams “activity”, and the Teams OAuth token. This token is crucial as it is used to communicate with Azure Bot Service when Amazon Connect returns a response.

2. Lambda function, after receiving the user’s id, Teams activity and Teams token, searches DynamoDB for user’s id.
a. The user’s id does not exist in DynamoDB. Lambda performs additional steps in Step 3.
b. The user’s id exists in DynamoDB. In this case, Lambda function extracts the Amazon Connection Token, Teams activity data and Teams token from DynamoDB response. Using this extracted information, Lambda perform tasks in Step 4.

3. When user’s id does not exist in DynamoDB, Lambda function must perform few actions on Amazon Connect to start the conversation.
a. First, Lambda function calls Amazon Connect “Start Chat Contact” API to establish a chat session with Amazon Connect.
b. It then calls Amazon Connect “Start Contact Streaming” API passing SNS topic ARN. This directs Amazon Connect to send responses from the Contact Control Plane (CCP) flow to the SNS topic.
c. Finally, Lambda function adds itself as a participant into the CCP flow chat by calling “Create Participant Connection”. This API call returns Amazon Connect Participant connection_token.
d. These APIs return number of key response ids, i.e. contact_id, participant_id, participant_token, streaming_id, connection_token. Lambda function stores this metadata into DynamoDB by relating Team’s user’s id and Amazon Connect contact_id. Teams activity payload and Teams token is also stored with this metadata. This DynamoDB record (or item) has a TTL value associated with it. Using the response ids, Lambda perform tasks in Step 4 next.

4. Using the connection_token from step 3c, Lambda function calls Amazon Connect Participant “Send Message” API to send user’s message to Amazon Connect.
a. Upon receiving an acknowledgement from Amazon Connect, Lambda function then invokes Microsoft BotBuilder framework to send Typing indicator message to Teams.
b. Teams shows a 3-dot animation to user indicating that the Chat Bot has received user’s message and is typing a response.

These sequences are better illustrated in the sequence diagram below.

Figure 2. Microsoft Teams initiates Amazon Connect Chat

Next, the following steps describe how the user receives responses in Microsoft Teams from Amazon Connect.

5. In step 4, Lambda proxy function sends user’s message to Amazon Connect using the Amazon Connect Participant “Send Message” API. Amazon Connect starts the CCP flow upon receiving the message. Refer to Amazon Connect CCP Flow section below for more details. The CCP flow calls Amazon Lex chat bot, which simply returns a mock response. Amazon Lex chat bot can perform many complex tasks including calling another Lambda Function to execute your own business logic.

6. Amazon Connect receives response from Amazon Lex chat bot and, upon successful execution of the CCP flow, sends this response to SNS topic. Recall that we specified the SNS topic ARN for Amazon Connect to respond to in Step 3b. This SNS topic must be configured to send messages to a Lambda function via subscription (Refer to Amazon SNS documentation). Lambda function, ‘Connect Stream Lambda’ provided in this solution, receives Amazon Connect payload and further processes it in next step. Refer to AWS Lambda function with Microsoft BotBuilder framework” section below for more implementation details.

7. The Connect Stream Lambda function extracts contact_id from SNS payload. It uses contact_id to look up Teams metadata. Recall that we saved several Amazon Connect ids and Microsoft Teams activity payload in DynamoDB in step 3d.
a. If a failure occurs while retrieving data from DynamoDB, an error is logged in CloudWatch. No response is sent to Microsoft Teams. The Typing indicator (3-dot animation) eventually times out in Teams UI. DynamoDB table items have a TTL value set. If TTL expires, DynamoDB service will expunge records that match the TTL threshold. This condition can error condition discussed here. Therefore, it is important to set the TTL value properly. For example, you may want to keep chat data in DynamoDB for an hour.
b. Once Lambda function successfully retrieves metadata for contact_id, it will use Microsoft BotBuilder framework to create a Teams “activity” object. The activity object contains the necessary information about which user in teams we want to send Amazon Connect response to.

8. The Lambda function invokes Microsoft BotBuilder with the activity data created in step 7b. It will send Amazon Connect (or Amazon Lex) response to Microsoft Azure Bot Service.

9. Azure Bot Service will send the response to Microsoft Teams targeting the correct user. Microsoft Team will stop the Typing indicator (3-dot animation) and render the response it received from Azure Bot service.

These sequences are better illustrated in the sequence diagram below.

Figure 3. Amazon Connect stream response to Microsoft Teams

Amazon Connect integration detailed design

This section describes Amazon Connect and Microsoft Teams integration.

Data design

The solution in this blog uses connect-session-table. This DynamoDB table stores Amazon Connect and Microsoft Teams activity data indexed by unique id, typically front-end specific user’s id. The table has a Global Secondary Index (GSI) set, which uses contact_id as the hash key. This GSI enables retrieval of stored Teams metadata using contact_id as hash key. This GSI based look-up is done in “Connect Stream Lambda”, discussed in following sections, to send Amazon Connect response to the Microsoft Teams via Azure Bot Service.

Additionally, connect-session-table has a TTL value associated with it. DynamoDB service will automatically expunge items from connect-session-table after TTL expires. Therefore, it is important to set the TTL value appropriately that indicates the average length of a user’s chat session. You can set the TTL value by setting CONNECT_SESSION_DDB_TABLE_TTL environment variable on chat-api-lambda function during deployment. Refer to GitHub for deployment details.

An example entry in DynamoDB table is shown below.

{
 "id": "team's user's id",
 "connection_token": "Amazon Connect Participant Service connection token",
 "contact_id": "Amazon Connect contact ID",
 "participant_id": "Amazon Connect participant ID",
 "participant_token": "Amazon Connect participant token",
 "payload": { <MS Teams Payload sent from Azure Bot Service.> }
 "streaming_id": "Amazon Connect streaming ID",
 "create_timestamp": "2024-09-04T12:49:10.129653-04:00",
 "last_update_timestamp": "2024-09-04T12:49:10.129653-04:00",
 "ttl": <epoch value as integer>
}

Refer to accompanying GitHub sample source code for more details.

API Gateway Lambda Proxy

Azure Bot Service invokes a REST API implemented using Amazon API Gateway service. The API calls a Lambda Proxy function, connect-api-lambda, which handles incoming REST API requests. Azure Bot Service performs HTTP POST operation on the API passing Microsoft Teams payload. Note that the sample implementation does not implement API authorization layer. However, it is possible to create Amazon API Gateway REQUEST type Authorizer Lambda function that checks Microsoft Teams JWT token validity. Read more about API Authorizers and how to write REQUEST type Authorizer Lambda function in AWS documentation. Refer to connect-api-lambda unit tests in GitHub for sample API payload.

As described in Architecture section sequence diagram, Figure 2, the connect-api-lambda function performs several steps on the incoming Microsoft Teams payload before initiating a chat session with Amazon Connect.

First, the connect-api-lambda function uses Microsoft BotBuilder Framework for Python to process incoming Teams message. It extracts user’s id, Teams Activity, and Teams OAuth Token. Teams OAuth token is extremely crucial as it is used to communicate with Azure Bot Service when Amazon Connect returns a response. The lambda function then validates if user’s id exists in DynamoDB connect-session-table. Note that user’s id is the hash key of connect-session-table. If user’s id does not exist in DynamoDB table, Lambda function performs following steps in sequence to establish a chat session with Amazon Connect:

1. Invoke Amazon Connect “Start Chat Contact” API to establish a chat session with Amazon Connect.

2. Invoke Amazon Connect “Start Contact Streaming” API passing SNS topic ARN. This directs Amazon Connect to send responses from the Contact Control Plane (CCP) flow to the SNS topic.

3. Add itself as a participant into the CCP flow chat by calling “Create Participant Connection”. This API call returns Amazon Connect Participant connection_token.

The connect-api-lambda function will store metadata received from Amazon Connect API invocations above into connect-session-table. This response metadata includes contact_id, participant_id, participant_token, streaming_id, connection_token. Refer to “Data Design” section above for more details regarding connect-session-table.

If connect-api-lambda function locates Microsoft Teams user’s id in connect-session-table, it will retrieve Amazon Connection Token, Teams Activity data, and Teams OAuth token from DynamoDB. It uses this information to send user’s message to Amazon Connect and also communicate with Azure Bot Service next.

Using the Amazon Connect connection_token, either received as a response from the “Create Participant Connection” call or retrieval of Amazon Connect metadata from DynamoDB, the connect-api-lambda function calls Amazon Connect Participant “Send Message” API to send user’s message to Amazon Connect. Once this API responds, connect-api-lambda function will invoke Microsoft BotBuilder framework to send Typing indicator message to Teams. Typing indicator shows a “3-dot” animation in Microsoft Teams UI indicating that the Chat Bot is typing a message back to user.

Azure Bot Service configuration

Several steps must be performed in Azure Portal to configure Azure Bot Services. These steps are documented in accompanying GitHub document. To summarize the Azure Bot setup process, you must have a Microsoft 365 subscription with appropriate administrative privileges. The subscription will allow you to sign into Microsoft 365 Admin Center, Azure Portal, and Teams Developer Portal. Next, you must create Azure Bot and ensure that messaging URL points to Amazon API Gateway API discussed above. You will get a unique Microsoft App Id for the Azure Bot. This App Id is used when packaging Teams application for deployment into Teams Developer Portal. Next, you can configure the Microsoft Entra ID to properly generate the JWT token (aka Teams Token) with correct scopes and permissions. Finally, you will deploy the Microsoft Teams application package you just created into Teams Developer Portal. The administrator of your Microsoft 365 account must “publish” the application you uploaded into Teams Developer Portal. This will make your application visible in Microsoft Teams under published application and usable by other members in your organization. You will use this application to interact with Amazon Connect.

Amazon Connect CCP flow and Amazon Lex

The Amazon Connect CCP Flow is a standard Contact Flow (inbound). CCP flow is shown in Figure 4 and 5. Figure 4 simply highlights basic setup that is done to start the flow. The flow supports both text and voice channels. At the core of this flow resides Amazon Lex with three intents. When a user types (or speaks) that they want to talk to Agent, the “TalktoAgent” intent in Lex is triggered. When user types (or says) “good bye”, the “GoodBye” Lex intent is triggered to disconnect the chat. The “Default” intent detects when users says “Hello”, “Hi” or any of the greetings (can be coded in Lex).

Note that Amazon Lex Chat Bot must be created using Amazon Lex console. Refer to the accompanying deployment steps in GitHub to deploy CCP flow and Amazon Lex chat bot.

Figure 4. Amazon Connect CCP Flow with Amazon Lex

Figure 5 shows how each Amazon Lex intent is handled. When speaking to Agent, the call is transferred to a “Sample Queue”. When either GoodBye or Default intents are triggered, the flow typically ends after the Lex response is sent to the user.

Figure 5. Amazon Connect CCP Flow with Amazon Lex

AWS Lambda function with Microsoft BotBuilder Framework

Finally, let’s go over the Connect Stream Lambda, also called connect-stream-lambda (refer to in accompanying GitHub code). This lambda function handles the response from Amazon Connect.

In the Architecture section sequence diagram, Figure 3, the lambda function receives message from Amazon Connect via SNS topic once Amazon Connect Participant “Send Message” API has successfully executed. This API sends user’s query into Amazon Connect. Amazon Connect CCP flow executes, and Amazon Lex determines the action to perform, i.e. talk to an agent, disconnect, or return a sample response back to user.

SNS topic receives several types of messages from Amazon Connect. Each message has an accompanying “Participant Role”. Participant roles include AGENT, CUSTOMER, SYSTEM, CUSTOM_BOT, and SUPERVISOR. The connect-stream-lambda function processes messages with all role types but only perform further action when the role is not CUSTOMER. In other words, when a message comes from an agent, a supervisor, or lex (system), this function will send the response to Azure Bot Service using Microsoft BotBuilder Framework.

The SNS payload contains contact_id; it represents the user’s contact_id who initiated the chat. The connect-stream-lambda function looks up the contact_id in DynamoDB connect-session-table using the GSI (discussed above in Data Design section).

If DynamoDB look-up operation fails or if contact_id is not present in connect-session-table, the function simply logs an error message. No response is sent to Azure Bot Service because Lambda function was not able to determine who is the target Microsoft Teams user. Additionally, the Typing indicator in Microsoft Teams UI will expire as well. This situation can happen when DynamoDB items were expunged from the table due to TTL expiry.

If DynamoDB look-up succeeds, connect-stream-lambda will extract the Microsoft Teams Activity object and Teams OAuth Token. The activity object contains the necessary information about target user to send Amazon Connect response to. The function uses Microsoft BotBuilder with the activity data retrieved, and Teams OAuth Token, to send Amazon Connect response (or Amazon Lex response) to Microsoft Azure Bot Service. Azure Bot Service will forward the response (based on the activity data provided) to the target user in Microsoft Teams UI. This action also stops the Typing indicator (3-dot animation).

Deployment

Complete the following steps to deploy the solution:

1. Open a command line terminal window.

2. Change to the deployment folder.

3. Edit the sample.tfvars file. Replace the variable values to match your AWS environment.

region = "us-east-1"
teams_app_client_id = "YOUR_TEAMS_APP_CLIENT_ID"
teams_app_client_secret = "YOUR_TEAMS_APP_CLIENT_SECRET"
teams_tenant_id = "YOUR_TEAMS_APP_TENANT_ID"

4. Run the following commands to deploy the solution:

$ terraform init
$ terraform apply -var-file=”sample.tfvars”

Detailed deployment steps are in the Deploy the solution section in the accompanying GitHub repository.

Test the solution

To test the solution, open the Microsoft Teams application package you published to Teams Developer Portal as discussed in “Azure Bot Service configuration” earlier. Start a new conversation with the chatbot inside the published Teams application. You can request for a password reset or get the status of a ticket by saying phrases like: “Can you help me reset my password” or “What is the status of the ticket?” respectively. Lex bot will send mock responses.

Clean-up

Use the following code to clean your AWS environment from the resources deployed in the previous section. You must use the same sample.tfvars that you used to deploy the solution.

$ terraform destroy -var-file=”sample.tfvars”

You must also delete the Azure bot and App registration in your Azure account. For detailed steps, refer to the clean-up section in GitHub.

Conclusion

In this blog post, we demonstrated how a large financial services organization advanced their cloud-first strategy by modernizing IT support capabilities through Amazon Connect and Microsoft Teams integration. This solution addresses the common enterprise challenge of high IT support call volumes by bringing intelligent self-service capabilities directly into employees’ daily workflow.

The technical integration exemplifies how enterprises can leverage cloud services to transform traditional support models. While the Microsoft Teams integration remains in pilot phase, the initial chatbot implementation has shown promising results in reducing call volumes and improving employee satisfaction with IT support services.

This implementation serves as a blueprint for enterprises looking to modernize support channels while maximizing cloud technology investments. It demonstrates how organizations can execute their cloud-first vision, leveraging AWS services to deliver innovative digital experiences for employees and clients.

Author Bio

Salman Moghal

Salman Moghal, a Principal Consultant at AWS Professional Services Canada, specializes in crafting secure Generative AI solutions for enterprises. With extensive experience in full-stack development, he excels in transforming complex technical challenges into practical business outcomes across banking, finance, and insurance sectors. In his downtime, he enjoys racquet sports and practicing Funakoshi Genshin’s teachings at his Martial Arts dojo.

Pratik Sharma

Pratik is a Delivery Consultant with AWS Professional Services, helping customers design and build scalable, serverless, and Generative AI-powered solutions. Passionate about automation and solving real-world problems with technology, he specializes in developing efficient cloud architectures, leveraging code and the AWS Cloud. When not optimizing cloud workflows, he explores sketching, tinkering with electronics and automating life with AI as a pastime.

AWS Contact Center