Teams Phone Extensibility (TPE) - Clarification on Resource Account, ACS Association, and Consent Flow

Hi there,

We're implementing a customer-developed TPE application using Azure Communication Services and Call Automation SDK, rather than deploying a third-party CCaaS solution. We are referring to the latest Microsoft documentation, including the updated guidance following the Azure Communication Services (ACS) retirement/breaking changes announcements.

Relevant documentation:

• Teams Phone Extensibility Quick Start
• Teams Phone Extensibility Provisioning and Authorization

For our initial proof of concept (PoC), the planned call flow is:

• A Teams user or external caller dials a Microsoft-assigned Teams phone number.
• The phone number is assigned to a Teams Resource Account.
• The Resource Account is associated with our ACS resource using Set-CsOnlineApplicationInstance -AcsResourceId.
• Our application uses the ACS Call Automation SDK to receive and handle the call.
• After the PoC is validated, we plan to reuse the same Resource Account and move to Direct Routing with an SBC (Session Border Controller) and carrier trunk.

Our current understanding is:

• The ACS resource is provisioned first.
• The Teams Resource Account is then created and licensed with a Teams Phone license.
• The Resource Account is associated with the ACS resource using Set-CsOnlineApplicationInstance -AcsResourceId.
• The association can be verified using the documented PowerShell commands.
• The Call Automation application can then interact with Teams Phone through the associated Resource Account.

Based on this understanding, we would appreciate clarification on the following points in light of the recent ACS retirement announcement:

1. For a customer-developed TPE solution (not via a CCaaS provider), is associating the Resource Account with ACS using Set-CsOnlineApplicationInstance -AcsResourceId sufficient, or is there an additional consent/authorization workflow that must be completed before calls can be handled by the Call Automation application?
2. The provisioning documentation mentions a Consent API that links the Teams Resource Account and the ACS resource. Is this a separate onboarding step from the Set-CsOnlineApplicationInstance association, or are they part of the same provisioning process? Is this also relevant to a customer-developed TPE solution?
3. After the Resource Account association has been completed, what are the expected onboarding steps before inbound and outbound calling scenarios are fully operational? Is there an end-to-end validation checklist for customer-developed TPE solutions?
4. When transitioning later from a Microsoft-assigned Teams phone number to Direct Routing, can the same Resource Account and ACS association be retained, or are there any re-provisioning requirements or limitations that should be considered?

We're trying to ensure we're following the supported onboarding model and correctly understand the relationship between Resource Account association, consent/authorization, and TPE call handling, ACS integration post the retirement announcement, before moving forward with implementation.

Many Thanks

A