Existing Developer Portal bot returns isSingleTenant=false despite single-tenant intent – identity-preserving clarification needed

Question

Existing Developer Portal bot returns isSingleTenant=false despite single-tenant intent – identity-preserving clarification needed

Morpheus Support 0

Hello Microsoft Teams developer support,

We need clarification for an existing Teams Developer Portal bot associated with an existing single-tenant Microsoft Entra application. We must preserve the existing application/client ID and bot registration. Deleting/recreating the bot or creating a second Entra application is not authorised. No Azure subscription is currently approved.

A fresh authenticated GET of /api/botframework/{existing-bot-id} returns HTTP 200. Our secret-safe comparison reports:

bot_id_matches: true

messaging_endpoint_matches: true

single_tenant_field_present: true

single_tenant_value: false

only_msteams_channel: true

calling_endpoint_state: null

This GET made no provider writes. READBACK_MISMATCH is our local validation failure, not a Microsoft HTTP error.

The original registration request used the existing client ID and included isSingleTenant:true, but a fresh GET returned false. We retained the attempt record and have not repeated registration. A separately approved name-only correction preserved all other fields. The Configure page exposes the messaging endpoint, but we found no tenant-setting control.

The existing app credential was accepted by the organisational tenant token endpoint for Bot Framework client-credentials authentication (HTTP 200). We do not treat token issuance as proof of bot tenant configuration or Teams delivery.

The personal setup user owns the backing application but has no assigned directory roles. We have not granted Application Developer or expanded administrative permissions.

Please clarify:

What is the authoritative meaning of isSingleTenant in this Developer Portal GET response? Does false establish multi-tenant bot configuration, or can it be a legacy/default projection independent of effective tenant binding?
What supported procedure can verify and, if necessary, correct this existing bot's tenant binding while preserving its bot/client ID and backing Entra application?
Does the bot-specific update endpoint support correcting this field? If so, what request contract, minimum permissions and fresh readback should be used? We have not attempted a speculative update.
If this field is not authoritative, what provider-side evidence should establish single-tenant configuration?
Does the Application Developer requirement apply when reusing an existing application, or only to new bot/service-principal creation?

Our approved scope is one personal Teams chat for one organisational user, without group/channel intake, Graph/mail/meeting/file permissions or general administrative-rights expansion. The gateway remains stopped pending clarification and subsequent delivery/authorisation tests.

No real identifiers, endpoint hostname, credentials or tokens are included in this public question.

Thank you.

0 comments

1 answer

Your answer

Answer 1

Hello

From what I was able to verify in Microsoft's public documentation, I could not find any article that explicitly states that the isSingleTenant value returned by the Developer Portal bot API is the authoritative indicator of whether a bot is configured as single-tenant or multi-tenant. Most Microsoft documentation describes tenant scope in terms of the underlying Microsoft Entra application configuration and bot registration settings, rather than this specific API field.

Because of that, I would be cautious about concluding that the bot is definitely multi-tenant solely because a GET request returns: "isSingleTenant": false

The closest related reference I found is Single-tenant bot compatibility with cross-tenant Graph API requests.

In the discussion, it notes that a bot's tenant configuration and its backing Microsoft Entra application's tenant configuration are not necessarily the same thing. Although the discussion does not specifically address the isSingleTenant field, it suggests that this value alone may not be enough to determine a bot's effective tenant configuration without further clarification from Microsoft.

To help determine whether this is an actual configuration issue or only a readback discrepancy, you can kindly check:

Apart from the GET response showing isSingleTenant:false, have you observed any actual multi-tenant behavior? For example, has the bot successfully been installed, accessed, or interacted with from another tenant?

Once again, at the moment, I have not found Microsoft documentation confirming that isSingleTenant:false alone is sufficient to prove that an existing bot is configured as multi-tenant. The information above may help provide additional context and support the investigation while you seek clarification regarding the purpose of the isSingleTenant field and how it should be interpreted in the Developer Portal response.

Kind regards,