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

Arup Kar 60 Reputation points
2026-10-10T18:16:28.47+00:00

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:

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

Azure Communication Services
Answer accepted by question author
Alex Burlachenko 26,435 Reputation points MVP Volunteer Moderator
2026-10-21T13:57:45.2433333+00:00

Hi Arup Kar & thx for join me at Q&A platform,

ur understanding is mostly correct, but there's one important distinction: associating the Teams Resource Account with ACS and granting consent are two separate operations. Both are required for the server-side TPE scenario u described.

Set-CsOnlineApplicationInstance -AcsResourceId establishes the routing association between the Teams Resource Account and ur ACS resource. After that, the Teams admin should run Sync-CsOnlineApplicationInstance to synchronize the configuration. However, this doesn't automatically authorize the ACS resource to receive and handle calls on behalf of that Resource Account.

The additional authorization is done through the Teams Phone Extension access assignments API. The ACS resource owner must issue a PUT request to /access/teamsExtension/tenants/{tenantId}/assignments/{resourceAccountObjectId}?api-version=2025-06-30, with "principalType": "teamsResourceAccount" in the request body. U can then verify the assignment using the corresponding GET request. Make sure the ID is the Resource Account's Entra object ID, not its UPN or the bot application ID.

For ur customer-developed application, this server-side consent is still required. It isn't exclusive to third-party CCaaS providers. Microsoft also confirms that Teams Contact Center Certification isn't mandatory to start building TPE solutions, although certification is recommended. The separate client-consent flow, including TeamsExtension.ManageCalls, becomes relevant when users access Teams Phone capabilities through a custom client rather than ur server-only Call Automation application.

For the PoC, I'd verify the Resource Account's bot application ID, ACS association, synchronization, Teams Phone Resource Account license, and assigned service number. Then configure the ACS Event Grid subscription and ur application's HTTPS callback endpoint. Make an inbound test call and confirm that ACS receives Microsoft.Communication.IncomingCall, that AnswerCallAsync succeeds, and that the expected Call Automation events arrive. For outbound calling, use a supported Call Automation SDK with TeamsAppSource set to the Resource Account's object ID, and verify the PSTN licensing and connectivity requirements. One detail worth checking: outbound calls using Microsoft Calling Plan numbers require the appropriate Pay-As-You-Go Calling Plan configuration.

Regarding the later move to Teams Direct Routing, u should generally be able to retain the same Resource Account and ACS association if the underlying identities and ACS resource remain unchanged. The change is primarily in the Teams PSTN configuration: configure and verify the SBC, assign the Direct Routing number, and apply the appropriate voice routing policy. I'd still revalidate the Resource Account synchronization, inbound routing, outbound calls, and caller ID after the cutover rather than assuming everything carries over automatically.

Finally, the ACS retirement announcement doesn't mean TPE itself is being retired. TPE is one of the supported Teams-integrated scenarios for continued use of ACS Call Automation. The retirement of standalone ACS Direct Routing is separate from using Teams Direct Routing with TPE, so ur planned architecture is aligned with Microsoft's supported direction.

I'd definitely complete both the Resource Account association and the server consent before testing call handling. That's the key missing step in the original provisioning sequence.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

Was this answer helpful?

1 person found this answer helpful.
Answer accepted by question author
Golla Venkata Pavani 7,695 Reputation points Microsoft External Staff Moderator
2026-10-11T00:53:23.2933333+00:00

Hi @Arup Kar

Thank you for reaching us regarding the issue.

Your understanding is mostly correct. The key point is that associating the Teams Resource Account with Azure Communication Services (ACS) and completing server authorization are separate steps.

Set-CsOnlineApplicationInstance`` ``-AcsResourceId associates the Resource Account with the ACS resource for routing, followed by Sync-CsOnlineApplicationInstance. However, before ACS can receive calls for that Resource Account, the ACS resource owner must also complete server authorization through the Teams Extension access assignments API. This applies to server-side solutions using the Call Automation SDK. Teams Phone System extensibility quick start.

For the PoC, ensure the Resource Account is correctly provisioned, associated and synchronized with ACS, has the required Teams Phone Resource Account license and phone number, and that the server authorization is completed. Then configure Event Grid/callback handling and validate inbound and outbound calling.

When moving later to Direct Routing, the documented TPE model supports it. Direct Routing requires a verified SBC, a Direct Routing number assigned to the Resource Account, and an appropriate Voice Routing Policy.

Finally, the current ACS documentation continues to document Teams Phone Extensibility provisioning and Call Automation, despite the ACS retirement/breaking-change notice. Teams Phone extensibility provisioning

Reference:
https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/tpe/teams-phone-extensibility-quickstart

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "accept" if the information helped you. This will help us and others in the community as well.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.