Share via

Microsoft Graph: Private channel SharePoint site URL naming appears to have changed

Kevin Vieira 20 Reputation points
2026-04-03T03:54:46.2766667+00:00

đź“„ Question

We are creating private channels using the Microsoft Graph API:

POST https://graph.microsoft.com/v1.0/teams/{team-id}/channels

With the following payload:

{
  "@odata.type": "#microsoft.graph.channel",
  "displayName": "Project-Channel-001",
  "description": "Sample private channel for testing",
  "membershipType": "private",
  "members": [
    {
      "@odata.type": "#microsoft.graph.aadUserConversationMember",
      "******@odata.bind": "https://graph.microsoft.com/v1.0/users/{user-id}",
      "roles": ["owner"]
    }
  ]
}

🔍 Observed Behavior

When the private channel is created, the associated SharePoint site is provisioned automatically (as expected).

However, the URL format appears to have changed.

Previously observed behavior:

https://{tenant}.sharepoint.com/sites/ProjectTeamURL-Project-Channel-001

Current behavior:

https://{tenant}.sharepoint.com/sites/ProjectTeamName-Project-Channel-001

âť— Impact

This change introduces several issues:

  • Breaks deterministic URL generation logic
  • Produces longer and less predictable URLs
  • Introduces dependency on display name, which is mutable and may contain unexpected characters
  • Impacts existing automation and integrations relying on the previous pattern

âť“ Questions

  1. Has there been a recent change in how SharePoint site URLs are generated for private channels?
  2. Is this behavior intentional and documented, or a regression?
  3. Is there any way (via Graph or otherwise) to:
    • Control the generated SharePoint site URL, or
    • Retrieve the final site URL deterministically without relying on pattern assumptions?
  4. Is the previous {ParentTeamUrl}-{ChannelName} format still expected in some scenarios, or has it been deprecated?

🧪 Additional Notes

  • This behavior is observed when creating channels via Microsoft Graph (v1.0)
  • The issue is reproducible across multiple test scenarios

🙏 Any clarification from Microsoft or others encountering this would be appreciated.

Microsoft 365 and Office | SharePoint | Development
0 comments
Answer accepted by question author
  1. Steven-N 23,865 Reputation points Microsoft External Staff Moderator
    2026-04-03T05:12:37.99+00:00

    Hi Kevin Vieira

    I have conducted some research and found this change in URL behavior is a common pain point for developers automating Teams/SharePoint provisioning. Microsoft frequently adjusts the backend provisioning logic for Microsoft 365 Groups, Teams, and SharePoint without explicit, detailed release notes on string-generation algorithms.

    Here are the answers to your questions, along with actionable guidance on how to future-proof your automation.

    1. Has there been a recent change in how SharePoint site URLs are generated for private channels?

    Yes. Instead of concatenating the parent Team's SharePoint site URL namespace with the channel name, it now strips special characters from the Parent Team's Display Name (ProjectTeamName) and concatenates it with the channel's display name.

    2. Is this behavior intentional and documented, or a regression?

    From my own research, I did not find Microsoft documentation that guarantees either:

    • {ParentTeamUrl}-{ChannelName}, or
    • {TeamDisplayName}-{ChannelName} as a contractual format for private channel site URLs.

    3. Is there any way to control or deterministically retrieve the URL?

    Practically, my answer is No, because there is currently no parameter in the Graph API POST /teams/{id}/channels payload to define or override the SharePoint site URL for a private channel. The provisioning engine handles this asynchronously and rigidly.

    However, about retrieving the URL deterministically, my answer is Yes, you should completely abandon URL pattern guessing. Instead, use the Graph API to ask Microsoft for the generated URL. Because the underlying SharePoint site and document library are often not fully provisioned until accessed, the most reliable method is to call the filesFolder endpoint. Calling this endpoint not only returns the URL but also forces the backend to finish provisioning the site if it hasn't already.

    4. Is the previous format still expected, or is it deprecated?

    You should consider the {ParentTeamUrl}-{ChannelName} format deprecated for new channel creations. Any existing private channels created under the old logic will retain their original SharePoint URLs (URLs do not retroactively update if MS changes the logic or if a Team display name changes). However, any automation for newly provisioned channels should immediately transition to the filesFolder Graph API check rather than relying on string manipulation.

    Hope my answer will help you.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-04-03T03:55:04.1566667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more
    1. Private channel SharePoint site URL behavior

    For private channels, each channel has its own SharePoint site that is distinct from the parent team’s site and is created with a special template (TEAMCHANNEL#0 or TEAMCHANNEL#1). The documentation explicitly states that:

    • Each private channel has its own SharePoint site.
    • These sites are “lightweight” and managed by Teams.
    • Site permissions and lifecycle are controlled by Teams, not SharePoint.

    The provided context does not document any specific or guaranteed naming pattern for the private channel site URL (for example, whether it uses the parent team URL vs. the parent team display name). It also does not describe or confirm any recent change in the URL pattern.

    Because of this, relying on a deterministic URL pattern for private channel sites is not supported.

    1. Whether the change is intentional, documented, or a regression

    The context does not contain any statement that:

    • A change was made from {ParentTeamUrl}-{ChannelName} to {ParentTeamName}-{ChannelName}, or
    • The previous pattern is guaranteed or documented.

    Therefore, the behavior must be treated as an implementation detail that can change and is not a supported contract.

    1. How to reliably get the SharePoint site / files location

    The supported and documented way to work with channel files (including private channels) is via Microsoft Graph, not by constructing SharePoint URLs:

    • Use the channel files root API: 
        GET /teams/{teamId}/channels/{channelId}/filesFolder
      This returns a driveItem representing the channel’s files root.
    • From the response, use:
      • parentReference.driveId → the SharePoint drive ID for the channel’s site.
      • id (or itemId in the docs) → the folder ID for the channel’s root.

    The documentation explicitly instructs not to hardcode library names or URLs or make assumptions about the team site location:

    Don’t hardcode library names or URLs based on assumptions about the team site, as the team site location can change. Use this GET /teams/{teamId}/channels/{channelId}/filesFolder API for all channel types.

    This applies directly to private channels and covers the scenario where URL patterns change.

    If the underlying SharePoint site URL is needed, it can be resolved via the SharePoint/drive metadata returned by Graph rather than by guessing the pattern. The context does not provide a direct “get site URL from channel” example, but it does show how to work with SharePoint sites and lists via Microsoft Graph using site and drive identifiers instead of URL patterns.

    1. Controlling or customizing the SharePoint site URL

    The context does not document any supported mechanism (via Graph or otherwise) to:

    • Control or override the SharePoint site URL for a private channel, or
    • Force a specific naming pattern.

    Teams manages the lifecycle and creation of private channel sites, and site permissions cannot be managed independently through SharePoint. That strongly implies that URL generation is also not intended to be controlled externally.

    1. Status of the “old” {ParentTeamUrl}-{ChannelName} pattern

    The context does not mention this pattern at all, nor does it state that any particular URL pattern is guaranteed or deprecated. As a result, any previously observed pattern must be treated as non-contractual and subject to change.

    1. Recommended approach for automation and integrations

    For automation and integrations that need to work with private channel storage:

    • Stop deriving SharePoint URLs from team/channel names or IDs.
    • Use the Graph channel files root API: 
        GET /teams/{teamId}/channels/{channelId}/filesFolder
    • Persist and reuse the returned driveId and folder id for subsequent file operations.
    • If a SharePoint site or list URL is required for other APIs, resolve it dynamically via Microsoft Graph using the drive or site identifiers rather than assuming a naming pattern.

    This approach is explicitly recommended and is resilient to any future changes in how Teams/SharePoint generate URLs for private, shared, or standard channels.

    References:

    0 comments

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.