Azure Document Intelligence - Deleted composed model name remains locked and cannot be reused

Question

Azure Document Intelligence - Deleted composed model name remains locked and cannot be reused

b u 0

Hi Azure Community & Support Team,

We are facing an issue with model management in Azure Document Intelligence (Form Recognizer Studio).

Issue Description:

We deleted an existing composed model named custom_model_v1.
The system indicates the model is deleted, and it no longer appears in our composed models list in the Studio workspace.
However, when trying to compose/recreate a new model using the exact same name (custom_model_v1), the UI blocks the action—the compose/train button disappears or remains unclickable.
Using a new model name (e.g., custom_model_v1_new) works without issues, but changing the model ID requires extensive updates across our database and codebase.

Environment:

Service: Azure Document Intelligence / Form Recognizer
Feature: Composed Model

Questions:

Is there a soft-delete retention period or backend cache delay for model names in Document Intelligence Studio?
Is there an Azure CLI or REST API command to hard-purge the old model reference so the original name can be freed up?

Any insights or workarounds would be greatly appreciated. Thanks!

0 comments

3 answers

Your answer

Answer 1

Hi,

Based on the symptoms described, I agree that the first thing to verify is whether the model ID is actually still present at the service/API level rather than relying only on the Studio UI.

I would suggest testing the GET request for custom_model_v1 first. If it returns 404, but the Studio still treats the ID as unavailable, testing the compose operation directly through the REST API would help distinguish between a Studio UI/cache issue and a backend metadata conflict.

If the API also returns a conflict for an ID that the GET operation reports as missing, that would provide strong evidence of a stale backend reference. In that case, opening a Microsoft Support request with the resource details, region, model ID, API version, timestamps, and correlation/request IDs would be the appropriate next step.

As a temporary workaround, keeping the existing model ID in the application and deploying the replacement under a new model ID may also avoid downtime while the issue is investigated.

Hope this helps.

Answer 2

We have also tried deleting the model from the Azure portal. However, the system reports that the model has already been deleted.

Despite this, in the Azure Document Intelligence / OCR training workspace, we are still unable to reuse the same model name, custom_model_v1. The UI does not allow us to enter or create a new model using that ID.

Since the model is already reported as deleted but the model ID is still unavailable, this appears to be an issue on the Microsoft/Azure backend side rather than within our application.

Could you please advise whether Microsoft Support needs to purge the stale model metadata from the backend?

Answer 3

Rukshan edirisinghe 165

Hi @b u

Direct answers to your two questions first.

There is no documented soft delete or name retention period for model IDs in Document Intelligence. A delete is supposed to be immediate and permanent. However, what you're hitting is a known pattern: deletion can leave orphaned model metadata in the backend that keeps the ID "taken" even though the model is gone from the Studio list. This has been reported before with the exact same symptoms.
There is no hard purge command, and no Azure CLI command for Document Intelligence model management at all (it's a data plane operation). The DELETE REST call is the only delete that exists. So the way forward is to find out where the stale reference lives:

Step 1. Check if the model still exists on the service, since the Studio list is not the source of truth:

GET {endpoint}/documentintelligence/documentModels/custom_model_v1?api-version=2024-11-30
Ocp-Apim-Subscription-Key: {your-key}

Step 2. If that returns 200, the model was never fully deleted. Delete it through the API:

DELETE {endpoint}/documentintelligence/documentModels/custom_model_v1?api-version=2024-11-30

A 204 response means it's gone. Then retry the compose.

Step 3. If the GET returns 404, the name is actually free on the service side and the block is only in Studio's UI validation. Do a hard refresh or try an incognito window, and if Studio still blocks it, bypass Studio and compose directly via the REST API (POST {endpoint}/documentintelligence/documentModels:compose) or the SDK, passing custom_model_v1 as the modelId. The service will accept it if the ID is really free.

Step 4. If the GET returns 404 but the compose API itself also rejects the ID with a conflict, that confirms orphaned backend metadata, and only Microsoft can purge it. Open a support request from the portal with the resource name, region, model ID and timestamps, and they can clear it server side.

References: https://learn.microsoft.com/en-us/rest/api/aiservices/document-models/delete-model?view=rest-aiservices-v4.0%20(2024-11-30) https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/how-to-guides/compose-custom-models?view=doc-intel-4.0.0

b u 0 Reputation points

2026-09-02T06:52:39.28+00:00

Hi Rukshan, Thank you so much for the detailed explanation and step-by-step guidance!

We have also tried deleting the model from the Azure portal. However, the system reports that the model has already been deleted.

Despite this, in the Azure Document Intelligence / OCR training workspace, we are still unable to reuse the same model name, custom_model_v1. The UI does not allow us to enter or create a new model using that ID.

Since the model is already reported as deleted but the model ID is still unavailable, this appears to be an issue on the Microsoft/Azure backend side rather than within our application.

Could you please advise whether Microsoft Support needs to purge the stale model metadata from the backend?
Rukshan edirisinghe 165 Reputation points

2026-09-03T01:56:46.7766667+00:00
Short answer: yes, if stale metadata is stuck on the backend, only Microsoft Support can purge it; nobody here can. But confirm it with the API first, because a Studio UI block on its own doesn't prove backend metadata is the cause, and the support ticket will need this evidence anyway.

One note on what you tried: the Azure portal doesn't manage individual Document Intelligence models, so "already deleted" there doesn't tell us the real backend state. Only the API does. Two calls settle it:

Check the ID directly:

GET {endpoint}/documentintelligence/documentModels/custom_model_v1?api-version=2024-11-30 Ocp-Apim-Subscription-Key: {your-key}

If this returns 200, the model still exists in the backend. Delete it with a DELETE to the same URL, and the name frees up. If it returns 404, the ID is genuinely free on the service side.

If you got 404, attempt the compose through the API with that same modelId (POST {endpoint}/documentintelligence/documentModels: compose) instead of Studio. Two possible outcomes:

It succeeds. Then the name was never locked; only Studio's UI validation is stale. Your application talks to the API anyway, so you can use the model normally and ignore the Studio quirk (clearing browser cache usually fixes the UI too).

It fails with a 409 / ModelExists conflict while the GET says 404. That is the confirmed signature of orphaned backend metadata, and that's when you raise the support request.

If you do open the ticket, include: subscription ID, resource name and region, the model ID, when it was deleted, and the raw request/response of both calls above with their x-ms-client-request-id values. State clearly that GET returns 404 while compose reports the ID as already existing. That evidence gets it routed straight to the product team for a backend purge instead of going through generic troubleshooting rounds. Short answer: yes, if stale metadata is stuck on the backend, only Microsoft Support can purge it; nobody here can. But confirm it with the API first, because a Studio UI block on its own doesn't prove backend metadata is the cause, and the support ticket will need this evidence anyway. One note on what you tried: the Azure portal doesn't manage individual Document Intelligence models, so "already deleted" there doesn't tell us the real backend state. Only the API does. Two calls settle it:

Check the ID directly:

GET {endpoint}/documentintelligence/documentModels/custom_model_v1?api-version=2024-11-30

Ocp-Apim-Subscription-Key: {your-key}

If this returns 200, the model still exists in the backend. Delete it with a DELETE to the same URL, and the name frees up. If it returns 404, the ID is genuinely free on the service side. 1. If you got 404, attempt the compose through the API with that same modelId (POST {endpoint}/documentintelligence/documentModels: compose) instead of Studio. Two possible outcomes: - It succeeds. Then the name was never locked; only Studio's UI validation is stale. Your application talks to the API anyway, so you can use the model normally and ignore the Studio quirk (clearing browser cache usually fixes the UI too). - It fails with a 409 / ModelExists conflict while the GET says 404. That is the confirmed signature of orphaned backend metadata, and that's when you raise the support request. 1. If you do open the ticket, include: subscription ID, resource name and region, the model ID, when it was deleted, and the raw request/response of both calls above with their x-ms-client-request-id values. State clearly that GET returns 404 while compose reports the ID as already existing. That evidence gets it routed straight to the product team for a backend purge instead of going through generic troubleshooting rounds.