Forum Discussion
Failed to delete Workspace Identity
When I try to delete the Workspace Identity it failed, I am the owner of this workspace and I created the workspace identity a couple months ago.
What I've tried:
1. Removed all existing connections which used the workspace identity;
2. Try fab cli to remove it, failed;
3. Try RestAPI to deprovisionIdentity, failed;
4. Try create and delete the workspace identity for another workspace I owned successfully.
Any clues on this issue would be greatly appreciated.
Hi Rom_Cheng,
Thanks, that API output helps narrow this down.
The important point is that 202 Accepted from deprovisionIdentity does not mean the identity was successfully deleted. Microsoft's Deprovision Identity API treats deletion as a long-running operation. A 202 response should include Location, x-ms-operation-id and Retry-After headers so the operation can be tracked.
Your current output only shows the status/body, so I would run it once with the response headers included:
fab api -X post "workspaces/<workspaceId>/deprovisionIdentity" --show_headersCapture the x-ms-operation-id, then check the actual backend operation:
fab api "operations/<operationId>" --show_headersMicrosoft's long-running operation API will show whether it is Running, Succeeded or Failed, and a failed operation should include the backend error details.
The subsequent WorkspaceIdentityAlreadyExists response is consistent with Fabric still considering the original identity provisioned, so I would avoid repeatedly calling provisionIdentity until the deprovision operation is understood.
Given that you have already waited around 72 hours and the workspace is still effectively stuck in DeleteFailed, I would not keep waiting indefinitely. If the operation reports Failed, or the 202 response does not contain the documented LRO headers, I would include that evidence in the Microsoft Support case.
I would provide them with the workspace ID, identity/application/service principal IDs, x-ms-operation-id, any operation error, request IDs and timestamps. If the Fabric Admin portal also cannot see/delete the identity while the workspace/API still report that it exists, I would mention that as well because it would be useful evidence of inconsistent service-side state.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
8 Replies
- GilbertQ
Super User
Hi Rom_Cheng
One further thing I would recommend is maybe wait a day or two to see if maybe it is just taking up at a time for the item to be deleted and then potentially run an API call to see if the workspace identity still exists.
Thanks and yes I've tried many times in last 72 hours.
- ShivekMaharaj
Community Champion
Hi Rom_Cheng,
Thanks, that API output helps narrow this down.
The important point is that 202 Accepted from deprovisionIdentity does not mean the identity was successfully deleted. Microsoft's Deprovision Identity API treats deletion as a long-running operation. A 202 response should include Location, x-ms-operation-id and Retry-After headers so the operation can be tracked.
Your current output only shows the status/body, so I would run it once with the response headers included:
fab api -X post "workspaces/<workspaceId>/deprovisionIdentity" --show_headersCapture the x-ms-operation-id, then check the actual backend operation:
fab api "operations/<operationId>" --show_headersMicrosoft's long-running operation API will show whether it is Running, Succeeded or Failed, and a failed operation should include the backend error details.
The subsequent WorkspaceIdentityAlreadyExists response is consistent with Fabric still considering the original identity provisioned, so I would avoid repeatedly calling provisionIdentity until the deprovision operation is understood.
Given that you have already waited around 72 hours and the workspace is still effectively stuck in DeleteFailed, I would not keep waiting indefinitely. If the operation reports Failed, or the 202 response does not contain the documented LRO headers, I would include that evidence in the Microsoft Support case.
I would provide them with the workspace ID, identity/application/service principal IDs, x-ms-operation-id, any operation error, request IDs and timestamps. If the Fabric Admin portal also cannot see/delete the identity while the workspace/API still report that it exists, I would mention that as well because it would be useful evidence of inconsistent service-side state.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
- ShivekMaharaj
Hi Rom_Cheng,
The Failed to delete state is an important clue here. Microsoft's workspace identity documentation actually lists DeleteFailed as one of the supported identity lifecycle states.
Since you have already tried the portal, Fabric CLI and the REST API, and deletion works in another workspace, I would first verify two things before doing any more cleanup.
First, confirm that your current role on this specific workspace is Admin. The Deprovision Identity REST API requires the caller to be a workspace Admin.
Second, check the exact REST response. Deprovisioning is a long-running operation, so a 202 Accepted is not a failure by itself. It should return a Location and x-ms-operation-id that can be used to track the operation. For an actual failure, I would keep the errorCode, requestId, isRetriable value and full response body.
I would also ask a Fabric Administrator to try deleting the identity from Admin portal > Fabric identities. Microsoft documents this as another supported administration path and it also exposes the identity state and state-change date.
I would not manually delete the associated Enterprise Application or App Registration in Entra. Microsoft specifically warns against modifying those objects because the workspace identity lifecycle is managed by Fabric.
Also, I don't see a documented requirement that every connection using the identity must be removed before deletion. Microsoft warns that those dependencies will break after deletion, but does not document them as blockers to deleting the identity.
If the Admin portal deletion also fails and the identity remains in DeleteFailed, I would raise a Microsoft Support case with the Workspace ID, identity/service principal/application IDs, timestamp and the REST requestId or x-ms-operation-id. I couldn't find a documented self-service recovery procedure for an identity already stuck in DeleteFailed.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Thanks for your support. I've tried many times in the last 72 hours. And it looks like the identity deletion is on a wrong status - it doesn't show up, it cannot be deleted, and it cannot be recreated. Yes the next step I may get Microsoft Support for this.
