Recover deleted environment via BAP API with service principal fails: "The user details for tenant id … and principal id … doesn't exist"

Sujith 5 Reputation points
2026-10-22T13:31:05.0733333+00:00

We recover soft-deleted Power Platform environments programmatically using an Entra app registration (service principal) with a client-credentials token for https://service.powerapps.com/.default:

POST https://api.bap.microsoft.com/providers/Microsoft.BusinessAppPlatform/scopes/admin/deletedEnvironments/{environmentName}/recover?api-version=2021-04-01
Body: {}

For most deleted environments this call succeeds and the environment is recovered. For some environments, the same call with the same service principal fails with:

The user details for tenant id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' and principal id '
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' doesn't exist.

What we've observed:

  • The failing environment is a Trial environment.
  • The same environment recovers successfully from the Power Platform admin center (Environments > Recently deleted environments > Recover) as a signed-in admin.
  • Other deleted environments recover fine with the same app-only API call, so app-only recovery works in general.
  • Deleting environments with the same service principal works fine.
  • Our service principal is added as an application user (via .../scopes/admin/environments/{env}/addAppUser) only to some environments, so it may not have been an application user of the failing environment before it was deleted.
  • The ids in the error are partly masked. The visible part of the principal id is …29fa-4246-9b47-1e67b56a9533.
  • We also tried the Power Platform API restore endpoint (POST https://api.powerplatform.com/environmentmanagement/environments/{id}/restore?api-version=2024-10-01). It returns 403 Forbidden with an empty body, but it restores a backup over a live environment, so it isn't the right operation for recovering a deleted environment.

Questions:

  1. What does this error mean for the recover operation? Which principal is the service trying to resolve: the caller (our service principal), or the environment's creator or owner?
  2. Why does the same app-only call succeed for most deleted environments but fail for some? Is there an environment property or condition (for example environment type such as Trial, how or by whom it was created, or whether the service principal was an application user of the environment before deletion) that makes recovery require a resolvable user principal?
  3. The same environment recovers successfully from the admin center as a signed-in admin. What does the API need, for example a specific header, api-version or prerequisite, so that the service principal can recover it too?
Microsoft 365 and Office | Install, redeem, activate | For business | Other
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-10-22T13:32:20.54+00:00

    No documented header or API-version change makes this BAP app-only request equivalent to an interactive recovery; because the same registered service principal recovers other environments and this environment recovers interactively, capture the failed request details and open a Microsoft support case for an environment-specific recovery-path failure.

    What can be concluded

    • The service principal is generally authorized correctly. Power Platform supports service-principal authentication for environment management, and a registered management application is treated similarly to a Power Platform administrator. Registration is tenant-level; the documentation does not state that the application must also have been a Dataverse application user in every environment it manages.^1^
    • The environment is recoverable. The successful admin-center recovery proves that it was still eligible for recovery and that storage capacity or the normal recovery window did not block this instance. The standard recovery window is seven days, with a 28-day exception for production environments containing Dynamics 365 applications.^2^
    • The error indicates a failed directory-principal lookup, but it does not identify the principal’s role. The available Microsoft documentation does not define this BAP error contract or say whether that GUID is the caller, creator, owner, “used by” user, or another environment-associated identity. Do not infer that it is the caller merely because the operation used app-only authentication.
    • Trial status and missing pre-deletion application-user membership are not documented triggers. There is no published requirement that a Trial environment, or an environment created by a particular user, needs a resolvable owner during recovery. Likewise, environment-level application-user creation is documented for connecting to Dataverse, not as a prerequisite for tenant-level deleted-environment recovery.^3^

    Therefore, the observed difference between environments cannot be assigned confidently to Trial type, creator/owner state, or application-user membership from the published contract.

    Collect evidence before escalation

    1. Record the complete response metadata from the failing BAP call:
      • UTC timestamp
      • Environment ID
      • Tenant ID
      • HTTP status and complete response body
      • x-ms-request-id, correlation ID, activity ID, or similar response headers
      • Token claims excluding the token itself, especially tid, appid, oid, and roles
    2. Compare the displayed principal ID with the token claims.
      • If it equals oid, it is the calling tenant service-principal object ID.
      • If it equals neither oid nor appid, it is evidence that the backend is resolving some other identity.
      • The masked suffix alone is insufficient to establish a match.
    3. Search active and deleted Entra objects using the full GUID. Check users, service principals, groups, and deleted items. If it is a soft-deleted service principal, Entra PowerShell can identify and restore it:^4^
    Connect-Entra -Scopes 'Application.Read.All'
Get-EntraDeletedServicePrincipal -All |
    Where-Object Id -eq '<full-principal-id>'

# Restore only if the returned object is confirmed as the required identity.
Connect-Entra -Scopes 'Application.ReadWrite.All'
Restore-EntraDeletedDirectoryObject -Id '<full-principal-id>'

    Restoring a directory object changes tenant identity state, so first confirm that the GUID is the intended object. Treat this as an investigative conditional step—not a documented fix for environment recovery.

    1. Search Entra audit records around environment creation and deletion. Historical audit data can establish whether the GUID represented the caller, creator, or another principal; a deleted object may otherwise appear only as “Identity not found.”^5^

    Supported reproduction for the support case

    Run the documented recovery cmdlet under the same service principal. This tests the supported PowerShell wrapper without switching to an interactive administrator:^6^

    Add-PowerAppsAccount -Endpoint prod `
    -TenantID $tenantId `
    -ApplicationId $appId `
    -ClientSecret $secret

Recover-AdminPowerAppEnvironment `
    -EnvironmentName $environmentId `
    -WaitUntilFinished $true `
    -Verbose

    The cmdlet has an optional -ApiVersion, defaulting to 2019-05-01, but Microsoft does not document changing it as a remedy for this principal-resolution error. If it fails identically, attach its verbose output to the case.

    The Power Platform API /restore operation should not be pursued further: as observed, backup restoration over an existing environment is a different operation from recovering a soft-deleted environment.

    Support request

    Open the request while the environment remains in its recovery window and include:

    • Both successful and failing deleted-environment IDs
    • Confirmation that the same app-only identity succeeds for other recoveries
    • Confirmation that interactive recovery succeeds for the failing Trial environment
    • Full missing principal GUID
    • Whether it exists as an active or deleted Entra object
    • BAP request/response headers and timestamp
    • PowerShell reproduction output
    • Environment creation type, creator, and deletion path if available

    Ask support to identify which environment metadata field supplied the unresolved principal ID and whether app-only recovery is invoking an undocumented user-resolution dependency for that environment.

    References

    1. Creating a service principal application using API (preview)
    2. Recover a recently deleted environment - Power Platform
    3. Microsoft Power Platform Build Tools for Azure DevOps
    4. Recover deleted data
    5. Finding out what info on a deleted ObjectID - Microsoft Q&A
    6. Recover-AdminPowerAppEnvironment-Description
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Ana Le 2,965 Reputation points Independent Advisor
    2026-10-22T14:01:49.8333333+00:00

    Hi Sujith,

    Thanks for the detailed comparison between the app-only request and recovery through the admin center. That helps narrow the investigation, although it does not yet establish why the affected environment behaves differently.

    As the forum’s AI answer recommended, collecting the failed request’s correlation IDs and testing the documented recovery cmdlet with the same service principal are reasonable next steps. I would clarify a few points before making changes to the application or environment.

    The error says that the service could not find user details for the specified tenant/principal pair. It does not tell us whether those details are missing from Microsoft Entra ID or from a Power Platform service, and it does not establish that the principal is the environment’s creator or owner. I could not find a Microsoft article documenting the exact meaning of this error for the BAP recovery operation.

    The most useful first check is to compare the full tenant and principal IDs in the error with tid and oid from the app-only token used for that failed request. Microsoft defines oid as the identifier of the requesting user or service principal. If both match, the error refers to your calling service principal’s identity. That still would not explain why its details cannot be resolved, or which internal field supplied that identity. If they do not match, the GUID needs further investigation; it should not automatically be treated as the creator or owner.

    Also distinguish oid from appid or azp: those identify the client application, rather than its tenant service-principal object.

    Reference: Microsoft identity platform — Access token claims reference.

    For the application-user question, Microsoft documents registering an application with Power Platform for tenant administration and supports service-principal authentication for environment management. However, that documentation does not specify that an application must have been a Dataverse application user in an environment before it was deleted to recover it afterward. I would therefore not treat missing application-user membership as the confirmed cause—or adding it as a confirmed fix.

    Likewise, the observations do not establish that Trial environments require a creator/owner lookup during app-only recovery. Trial type, creation history, and application-user membership are useful details to compare between successful and failing cases, but they remain hypotheses.

    Reference: Creating a service principal application using PowerShell

    I could not find a documented header, API-version change, or additional prerequisite that resolves this particular error. Successful recovery through the admin center confirms that this environment was recoverable at that time; it does not establish that the interactive and app-only requests have identical requirements.

    If the environment has already been recovered, there is no need to delete it again just to reproduce the issue. Use the existing evidence to open a Power Platform support request. Include the failed request’s UTC timestamp, environment ID, full error and response headers, and a successful app-only comparison. Share diagnostic details privately with support, without access tokens or client secrets.

    The key question for support is: Which identity lookup failed, where did that principal ID come from, and is the failure due to an additional prerequisite, an unsupported scenario, or a service defect? Those details require service-side investigation that we cannot perform from this forum.

    Finally, you are correct about /restore: Microsoft documents that operation as restoring a backup into a target environment that will be overwritten. It is not a substitute for recovering a soft-deleted environment, and its separate 403 response does not explain the BAP error.

    Reference: Environment Restore — Restore Environment.

    Was this answer helpful?

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.