Merge pull request #269993 from vac0224/vc-data-retention-new

Chat data retention changes

Author: v-ccolin

articles/communication-services/concepts/chat/concepts.md

@@ -14,7 +14,7 @@ ms.subservice: chat
 
 # Chat concepts
 
-Azure Communication Services Chat can help you add real-time text communication to your cross-platform applications. This page summarizes key Chat concepts and capabilities. See the [Communication Services Chat Software Development Kit (SDK) Overview](./sdk-features.md) for lists of SDKs, languages, platforms, and detailed feature support. 
+Azure Communication Services Chat can help you add real-time text communication to your cross-platform applications. This page summarizes key Chat concepts and capabilities. See the [Communication Services Chat Software Development Kit (SDK) Overview](./sdk-features.md) for lists of SDKs, languages, platforms, and detailed feature support.
 
 The Chat APIs provide an **auto-scaling** service for persistently stored text and data communication. Other key features include:
 
@@ -24,7 +24,6 @@ The Chat APIs provide an **auto-scaling** service for persistently stored text a
 - **Real-time Notifications** - Chat SDKs use efficient persistent connectivity (WebSockets) to receive real-time notifications such as when a remote user is typing. When apps are running in the background, built-in functionality is available to [fire pop-up notifications](../notifications.md) ("toasts") to inform end users of new threads and messages.
 - **Bot Extensibility** - It's easy to add Azure bots to the Chat service with [Azure Bot integration](../../quickstarts/chat/quickstart-botframework-integration.md).
 
-
 ## Chat overview
 
 Chat conversations happen within **chat threads**. Chat threads have the following properties:
@@ -39,28 +38,35 @@ Chat conversations happen within **chat threads**. Chat threads have the followi
 Azure Communication Services supports three levels of user access control, using the chat tokens. See [Identity and Tokens](../identity-model.md) for details. Participants don't have write-access to messages sent by other participants, which means only the message sender can update or delete their sent messages. If another participant tries to do that, they get an error. 
 
 ### Chat Data 
-Azure Communication Services stores chat messages indefinitely until they are deleted by the customer. Chat thread participants can use `ListMessages` to view  message history for a particular thread. Users that are removed from a chat thread are able to view previous message history but can't send or receive new messages. Accidentally deleted messages aren't recoverable by the system. To learn more about data being stored in Azure Communication Services chat service, refer to the [data residency and privacy page](../privacy.md).  
+Azure Communication Services stores chat threads according to the [data retention policy](/purview/create-retention-policies) in effect when the thread is created. You can update the retention policy if needed during the retention time period you set. After you delete a chat thread (by policy or by a Delete API request), it can't be retrieved.
+
+[!INCLUDE [public-preview-notice.md](../../includes/public-preview-include-document.md)]
+
+You can choose between indefinite thread retention, automatic deletion between 30 and 90 days via the retention policy on the [Create Chat Thread API](/rest/api/communication/chat/chat/create-chat-thread), or immediate deletion using the APIs [Delete Chat Message](/rest/api/communication/chat/chat-thread/delete-chat-message) or [Delete Chat Thread](/rest/api/communication/chat/chat/delete-chat-thread). 
 
-In 2024, new functionality will be introduced where customers must choose between indefinite message retention or automatic deletion after 90 days. Existing messages remain unaffected.
+Any thread created before the new retention policy isn't affected unless you specifically change the policy for that thread. If you submit a support request for a deleted chat thread more than 30 days after the retention policy has deleted that thread, it can no longer be retrieved and no information about that thread is available. If needed, open a support ticket as quickly as possible within the 30 day window after you create a thread so we can assist you.
+
+Chat thread participants can use `ListMessages` to view message history for a particular thread. The `ListMessages` API can't return the history of a thread if the thread is deleted. Users that are removed from a chat thread are able to view previous message history but can't send or receive new messages. Accidentally deleted messages aren't recoverable by the system. To learn more about data being stored in Azure Communication Services chat service, refer to the [data residency and privacy page](../privacy.md). 
 
 For customers that use Virtual appointments, refer to our Teams Interoperability [user privacy](../interop/guest/privacy.md#chat-storage) for storage of chat messages in Teams meetings.
 
 ### Service limits
 - The maximum number of participants allowed in a chat thread is 250.
 - The maximum message size allowed is approximately 28 KB.
-- For chat threads with more than 20 participants, read receipts and typing indicator features are not supported.
-- For Teams Interop scenarios, it is the number of Azure Communication Services users, not Teams users, that must be below 20 for the typing indicator feature to be supported.
+- For chat threads with more than 20 participants, read receipts and typing indicator features aren't supported.
+- For Teams Interop scenarios, it's the number of Azure Communication Services users, not Teams users, that must be below 20 for the typing indicator feature to be supported.
+- When creating a chat thread, you can set the retention policy between 30 and 90 days.
 - For Teams Interop scenarios, the typing indicator event might contain a blank display name when sent from Teams user.
 - For Teams Interop scenarios, read receipts aren't supported for Teams users.
 
 ## Chat architecture
 
-There are two core parts to chat architecture: 1) Trusted Service and 2) Client Application.
+There are two core parts to chat architecture: 1) Trusted service and 2) Client application.
 
 :::image type="content" source="../../media/chat-architecture-updated.svg" alt-text="Diagram showing Communication Services' chat architecture.":::
 
- - **Trusted service:** To properly manage a chat session, you need a service that helps you connect to Communication Services by using your resource connection string. This service is responsible for creating chat threads, adding and removing participants, and issuing access tokens to users. More information about access tokens can be found in our [access tokens](../../quickstarts/identity/access-tokens.md) quickstart.
- - **Client app:**  The client application connects to your trusted service and receives the access tokens that are used by users to connect directly to Communication Services. After creating the chat thread and adding users as participants, they can use the client application to connect to the chat thread and send messages. Real-time notifications in your client application can be used to subscribe to message & thread updates from other participants.
+ - **Trusted service:** To properly manage a chat session, you need a service that helps you connect to Communication Services by using your resource connection string. This service is responsible for creating chat threads, adding and removing participants, and issuing access tokens to users. For more information, see [Quickstart: Create and manage access tokens](../../quickstarts/identity/access-tokens.md) quickstart.
+ - **Client app:**  The client application connects to your trusted service and receives the access tokens that users need to connect directly to Communication Services. After you create the chat thread and add participants, they can use the client application to connect to the chat thread and send messages. Participants can use real-time notifications in your client application to subscribe to message & thread updates from other members.
 
 ## Build intelligent, AI-powered chat experiences
 
@@ -87,9 +93,9 @@ When you call `List Messages` or `Get Messages` on a chat thread, the result con
  - `html`: A formatted message using html, composed and sent by a user as part of chat thread. 
 
 Types of system messages: 
- - `participantAdded`: System message that indicates one or more participants have been added to the chat thread.
+ - `participantAdded`: System message that indicates one or more participants are in the chat thread.
  - `participantRemoved`: System message that indicates a participant has been removed from the chat thread.
- - `topicUpdated`: System message that indicates the thread topic has been updated.
+ - `topicUpdated`: System message that indicates the thread topic is updated.
 
 ## Real-time notifications
 
@@ -118,19 +124,19 @@ This feature lets server applications listen to events such as when a message is
 
 ## Push notifications 
 
-Android and iOS Chat SDKs support push notifications. To send push notifications for messages missed by your users while they were away, connect a Notification Hub resource with Communication Services resource to send push notifications. Doing so will notify your application users about incoming chats and messages when the mobile app is not running in the foreground.    
+Android and iOS Chat SDKs support push notifications. To send push notifications for messages missed by your participants while they were away, connect a Notification Hub resource with Communication Services resource to send push notifications. Doing this notifies your application participants about incoming chats and messages when the mobile app is not running in the foreground.    
 
 IOS and Android SDK support the below event:
-- `chatMessageReceived` - when a new message is sent to a chat thread by a participant.     
+- `chatMessageReceived` - when a participant sends a new message to a chat thread.     
 
 Android SDK supports extra events:
-- `chatMessageEdited` - when a message is edited in a chat thread.	
-- `chatMessageDeleted` - when a message is deleted in a chat thread.	
+- `chatMessageEdited` - when a participant edits a message in a chat thread.	
+- `chatMessageDeleted` - when a participant deletes a message in a chat thread.	
 - `chatThreadCreated` - when a Communication Services user creates a chat thread.	
 - `chatThreadDeleted` - when a Communication Services user deletes a chat thread.	
-- `chatThreadPropertiesUpdated` - when chat thread properties are updated; currently, only updating the topic for the thread is supported.	
-- `participantsAdded` - when a user is added as a chat thread participant. 	
-- `participantsRemoved` - when an existing participant is removed from the chat thread.
+- `chatThreadPropertiesUpdated` - when you update chat thread properties; currently, only updating the topic for the thread is supported.	
+- `participantsAdded` - when you add a participant to a chat thread. 	
+- `participantsRemoved` - when you remove an existing participant from the chat thread.
 
 For more information, see [Push Notifications](../notifications.md).
 
@@ -142,5 +148,6 @@ For more information, see [Push Notifications](../notifications.md).
 > [!div class="nextstepaction"]
 > [Get started with chat](../../quickstarts/chat/get-started.md)
 
-The following documents may be interesting to you:
-- Familiarize yourself with the [Chat SDK](sdk-features.md)
+## Related articles
+
+- Familiarize yourself with the [Chat SDK](./sdk-features.md)

articles/communication-services/concepts/service-limits.md

@@ -1,7 +1,7 @@
 ---
 title: Service limits for Azure Communication Services
 titleSuffix: An Azure Communication Services how-to document
-description: Learn how to
+description: Learn how to handle service limits.
 author: tophpalmer
 manager: sundraman
 services: azure-communication-services
@@ -17,18 +17,23 @@ ms.subservice: data
 This document explains the limitations of Azure Communication Services APIs and possible resolutions.
 
 ## Throttling patterns and architecture
-When you hit service limitations, you will receive an HTTP status code 429 (Too many requests). In general, the following are best practices for handling throttling:
+When you hit service limitations, you receive an HTTP status code 429 (Too many requests). In general, the following are best practices for handling throttling:
 
 - Reduce the number of operations per request.
 - Reduce the frequency of calls.
 - Avoid immediate retries because all requests accrue against your usage limits.
 
 You can find more general guidance on how to set up your service architecture to handle throttling and limitations in the [Azure Architecture](/azure/architecture) documentation for [throttling patterns](/azure/architecture/patterns/throttling). Throttling limits can be increased through a request to Azure Support.
 
-1.  Go to Azure portal
-1.  Select Help+Support
-1.  Click on Create new support request
-1.  In the Problem description, please choose **Issue type** as **Technical** and add in the details.
+1. Open the [Azure portal](https://ms.portal.azure.com/) and sign in.
+2. Select [Help+Support](https://ms.portal.azure.com/#view/Microsoft_Azure_Support/HelpAndSupportBlade/~/overview).
+3. Click **Create new support request**.
+4. In the **Describe your issue** text box, enter `Technical` then click **Go**. 
+5. From the **Select a service** dropdown menu, select **Service and Subscription Limits (Quotas)** then click **Next**.
+6. At the Problem description, choose the **Issue type**, **Subscription**, and **Quota type** then click **Next**.
+7. Review any **Recommended solution** if available, then click **Next**.
+8. Add **Additional details** as needed, then click **Next**.
+9. At **Review + create** check the information, make changes as needed, then click **Create**.
 
 You can follow the documentation for [creating request to Azure Support](../../azure-portal/supportability/how-to-create-azure-support-request.md).
 
@@ -63,7 +68,7 @@ We recommend acquiring identities and tokens before creating chat threads or sta
 For more information, see the [identity concept overview](./authentication.md) page.
 
 ## SMS
-When sending or receiving a high volume of messages, you might receive a ```429``` error. This error indicates you're hitting the service limitations, and your messages will be queued to be sent once the number of requests is below the threshold.
+When sending or receiving a high volume of messages, you might receive a ```429``` error. This error indicates you're hitting the service limitations, and your messages are queued to be sent once the number of requests is below the threshold.
 
 Rate Limits for SMS:
 
@@ -80,7 +85,8 @@ If you have requirements that exceed the rate-limits, submit [a request to Azure
 For more information on the SMS SDK and service, see the [SMS SDK overview](./sms/sdk-features.md) page or the [SMS FAQ](./sms/sms-faq.md) page.
 
 ## Email
-There is a limit on the number of email messages you can send. If you exceed the below limits on your subscription, your requests will be rejected. You can attempt these requests again, after the Retry-After time has passed. Please take necessary action and request to raise the sending volume limits if needed.
+
+There is a limit on the number of email messages you can send for a given period of time. If you exceed the following limits on your subscription, your requests are rejected. You can attempt these requests again, when the Retry-After time has passed. You can make a request to raise the sending volume limits if needed.
 
 ### Rate Limits 
 
@@ -110,7 +116,7 @@ There is a limit on the number of email messages you can send. If you exceed the
 |Total email request size (including attachments) |10 MB |
 
 ### Action to take
-This sandbox setup is to help developers start building the application. Once you have established a sender reputation by sending mails, you can request to increase the sending volume limits. Submit a [support request](https://azure.microsoft.com/support/create-ticket/) to raise your desired email sending limit if you require sending a volume of messages exceeding the rate limits. Email quota increase requests are not automatically approved. The reviewing team will consider your overall sender reputation, which includes factors such as your email delivery failure rates, your domain reputation, and reports of spam and abuse when determining approval status.
+This sandbox setup is to help developers start building the application. Once you have established a sender reputation by sending mails, you can request to increase the sending volume limits. Submit a [support request](https://azure.microsoft.com/support/create-ticket/) to raise your desired email sending limit if you require sending a volume of messages exceeding the rate limits. Email quota increase requests aren't automatically approved. The reviewing team considers your overall sender reputation, which includes factors such as your email delivery failure rates, your domain reputation, and reports of spam and abuse when determining approval status.
 
 > [!NOTE]
 > Email quota increase requests may take up to 72 hours to be evaluated and approved, especially for requests that come in on Friday afternoon.
@@ -154,12 +160,17 @@ This sandbox setup is to help developers start building the application. Once yo
 > ** Read receipts and typing indicators are not supported on chat threads with more than 20 participants. 
 
 ### Chat storage
-Azure Communication Services stores chat messages indefinitely till they are deleted by the customer. 
+Azure Communication Services stores chat messages according to the retention policy you set when you create a chat thread.
+
+[!INCLUDE [public-preview-notice.md](../includes/public-preview-include-document.md)]
+
+You can choose between indefinite message retention or automatic deletion between 30 and 90 days via the retention policy on the [Create Chat Thread API](/rest/api/communication/chat/chat/create-chat-thread).
+Alternatively, you can choose not to set a retention policy on a chat thread.
 
-Beginning in CY24 Q1, customers must choose between indefinite message retention or automatic deletion after 90 days. Existing messages remain unaffected, but customers can opt for a 90-day retention period if desired.
+If you have strict compliance needs, we recommend that you delete chat threads using the API [Delete Chat Thread](/rest/api/communication/chat/chat/delete-chat-thread). Any threads created before the new retention policy aren't affected unless you specifically change the policy for that thread.
 
 > [!NOTE] 
-> Accidentally deleted messages are not recoverable by the system.
+> If you accidentally deleted messages, they can't be recovered by the system. Additionally, if you submit a support request for a deleted chat thread after the retention policy has deleted that thread, it can no longer be retrieved and no information about that thread is available. If needed, open a support ticket as quickly as possible within the 30 day window after you created a thread so we can assist you.
 
 ## Voice and video calling
 
@@ -183,7 +194,7 @@ The Communication Services Calling SDK supports the following streaming configur
 | **Maximum # of outgoing local streams that you can send simultaneously**     | one video or one screen sharing | one video + one screen sharing |
 | **Maximum # of incoming remote streams that you can render simultaneously** | 9 videos + one screen sharing | 9 videos + one screen sharing |
 
-While the Calling SDK will not enforce these limits, your users may experience performance degradation if they're exceeded.
+While the Calling SDK won't enforce these limits, your users may experience performance degradation if they're exceeded.
 
 ### Calling SDK timeouts