dataverse_list_shared_principals

Answer "WHO has this record because it was SHARED with them?".

Merges two unbound Web API functions that answer one question:

• RetrieveSharedPrincipalsAndAccess — the principals the record was shared with, and the access rights each was given.

• RetrieveSharedLinks — the existing shared links over the record that the caller is allowed to see.

This is the list neither neighbouring tool can produce. dataverse_retrieve_principal_access answers "which rights does ONE named principal have" (the mask), dataverse_retrieve_access_origin answers "WHY does ONE named principal have them" — both need you to already know who to ask about. This one enumerates them.

MIND THE INPUT ASYMMETRY. This tool takes the PLURAL entity_set_name ('accounts'), because the target is expressed as an OData EntityReference and an @odata.id names a collection. dataverse_retrieve_access_origin takes the SINGULAR logical_name ('account'). Confusing the two is the easy caller error here — use dataverse_get_entity_sets to confirm the plural, which is irregular often enough ('webresourceset') that guessing costs a 404.

A WRONG ENTITY SET NAME LOOKS EXACTLY LIKE A MISSING RECORD. VERIFIED LIVE: a nonexistent record id and a VALID id paired with the WRONG entity set both return HTTP 404 [0x80040217] "Entity '' With Id = Does Not Exist" from BOTH functions — the same status, the same error code, indistinguishable text. Both calls therefore fail and you get the standard {"error": true, "message": ...} envelope. So when this tool errors with "Does Not Exist", CHECK THE ENTITY SET NAME FIRST (plural — 'accounts', not 'account'; see the asymmetry note above) before concluding the record is gone. That singular-for-plural slip is the likeliest cause and it misdiagnoses as a missing record.

THE TWO CALLS FAIL INDEPENDENTLY. Each is made on its own: if one is unavailable or privilege-gated, its failure is reported in partial_errors and the other's data is still returned. Only a failure of BOTH yields the standard {"error": true, "message": ...} envelope. RetrieveSharedLinks is in principle the more likely of the two to be missing (it was available on the org tested, never landing in partial_errors), so a partial_errors entry naming it is an expected outcome rather than an error — check partial_errors before concluding a record is unshared.

RESPONSE SHAPES (verified live). Microsoft Learn documents RetrieveSharedPrincipalsAndAccessResponse but not its inner properties; live runs confirm the collection arrives under PrincipalAccesses, and that is the name tried first before the by-shape fallback. RetrieveSharedLinks returns Collection(team), an ordinary OData collection, and its entries duly arrive under the standard 'value' property. Each block reports the source it was found under — check it. If a payload cannot be identified unambiguously that block carries normalized: false, no counts, and the raw payload (minus the @odata.* envelope) under raw_response; nothing is fabricated.

Both lists are trimmed to top (default 50, max 1000) because neither function pages server-side. count, total_count and has_more are reported per block and total_count is always the full number Dataverse returned.

An empty result is NOT proof the record is private: these functions report explicit shares (the POA table) that the CALLER can see, not access granted by ownership, security roles, team membership or the business-unit hierarchy. Use dataverse_retrieve_access_origin for a specific principal, and read partial_errors before drawing any conclusion.