Microsoft Purview: Glossary creation ignores domain_id provided in payload

Question

I am programmatically trying to create a new glossary in Purview, but under a root collection (aka, domain) that is not the default one.

If I do this using the UI and intercept the payload, this is what I get:

{
	"name": "TestGlossary1",
	"longDescription": "Something",
	"domainId": "abc123",
	"contacts": {
		"Expert": [
			{
				"id": "<expert_guid>"
			}
		],
		"Steward": [
			{
				"id": "<steward_guid>"
			}
		]
	}
}

But if I do this programmatically and generate a payload that's exactly like the one above:

{
    "name": "TestGlossary2",
    "longDescription": "Something",
    "domainId": "abc123",
    "contacts": {
        "Expert": [
            {
                "id": "<expert_guid>"
            }
        ],
        "Steward": [
            {
                "id": "<steward_guid>"
            }
        ]
    }
}

The second payload is passed as argument to this call:

catalog_client.glossary.create_glossary(payload)

The result is that the new glossary is created, but not where I want it to be, but under the root collection (aka, domain).

As you can see, the two payloads are EXACTLY the same. Is this a bug? Am I using the wrong method to create a glossary under a specific domain? Thanks.

Answer 1

Hi Francesco Castellani
When creating a glossary programmatically in Microsoft Purview, the Glossary API is not collection-scoped during creation. Even if a domainId is included in the payload, the service may still create the glossary under the default/root domain because glossary resources are managed by the Atlas catalog service rather than by Purview collections.

In Purview, collections primarily control governance, access, and organization, while glossaries exist at the catalog level. Because of this architecture, specifying a domain or root collection in the request body may appear to be ignored this is platform behavior rather than a payload issue.

Recommended approach: call the Atlas Glossary endpoint (/atlas/v2/glossary) to create the glossary, then manage access or logical separation using collections, roles, or post-creation governance instead of relying on domainId during creation. Domain placement is not guaranteed through the create glossary API.

Answer 2

It seems that you are encountering an issue where the domainId specified in your payload is being ignored when creating a glossary programmatically in Microsoft Purview. This could be due to a few reasons:

1. API Method Limitations: Ensure that the method you are using (catalog_client.glossary.create_glossary(payload)) supports specifying a domainId. Sometimes, certain methods may default to the root domain if they do not properly handle the domain context.
2. Permissions: Verify that the account or service principal you are using to authenticate has the necessary permissions to create glossaries in the specified domain. Lack of permissions might cause the API to revert to the default domain.
3. Payload Structure: While the payloads appear identical, there might be subtle differences in how the data is being sent or processed in the API call. Make sure that the payload is correctly formatted and that there are no hidden characters or formatting issues.
4. API Version: Check if there are any updates or changes in the API documentation regarding glossary creation that might affect how the domainId is handled. Sometimes, APIs evolve, and certain parameters may be deprecated or modified.

If after checking these points the issue persists, it may be beneficial to reach out to Microsoft support or consult the official documentation for further assistance regarding this behavior.

---

References:

• Create and manage classic business glossaries
• Microsoft Purview domains and collections architectures and best practices