dynamics v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-dynamics-dataverse-access-token

Custody

customer_vault

Injection

header (Authorization)

An OAuth2 access token for the customer's own Dataverse environment, held in the client's own secret manager. The stored material must be the complete Authorization header value (scheme included): 'Bearer', one separating space, then the access token. An external deployment process obtains the token with the OAuth 2.0 client credentials grant — POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token with the environment URL as the resource (scope '<org-url>/.default') — and renews it before expiry, storing the new complete header value each time. Storing the app registration's client secret under this reference does not make the HTTP injector perform OAuth: the injector injects the stored value verbatim, so token lifecycle (including secret rotation on the app registration) sits entirely with that external process, and the client secret itself must never be the stored value. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. Access tokens are short-lived (the token response carries expires_in). Distinguish the revocation paths: disabling the application user in the environment or removing its security role stops the environment from honoring further calls; removing the app registration's secret stops future token acquisition — but secret removal does not by itself invalidate already-issued access tokens, which remain usable until they expire (typically about an hour). Plan any emergency revocation around that residual validity window. An expired value fails closed. Least privilege: the application user's custom security role should grant read on accounts, contacts and opportunities, update on opportunities, and nothing more — no create, delete, append-to or assign privileges beyond what the registered capabilities need. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• dynamics-org-accounts (api, pii): https://dynamics-org.invalid/api/data/v9.2/accounts
• dynamics-org-contacts (api, pii): https://dynamics-org.invalid/api/data/v9.2/contacts
• dynamics-org-opportunities (api, internal): https://dynamics-org.invalid/api/data/v9.2/opportunities
• dynamics-org-identity (api, internal): https://dynamics-org.invalid/api/data/v9.2/WhoAmI

The endpoint host 'dynamics-org.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Dataverse environment host (Microsoft's documentation writes it as [Organization URI], of the form yourorg.crm.dynamics.com or yourorg.api.crm.dynamics.com) before enabling, in every endpoint, in every resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable. The Web API version segment v9.2 is pinned as documented. This pack registers only endpoints Microsoft's Dataverse Web API documentation describes: collection reads on the accounts, contacts and opportunities entity sets, the WhoAmI unbound function, and PATCH update of one opportunity record. All reads are collection reads only: single-record reads (accounts(GUID), contacts(GUID), opportunities(GUID)) exist in the API and are deliberately not registered. The opportunity update registers PATCH /opportunities(OPPORTUNITY_ID): Microsoft's update guidance documents that PATCH without If-Match behaves as an upsert that can create a record, so the deployment's adapter must send If-Match: * to keep this capability an update only. This registration does not restrict which writable columns a request may carry, and Microsoft's opportunity reference documents that status changes run through the same PATCH (statecode and statuscode, the SetState message) and that ownership reassignment (Assign) is PATCH of ownerid — so this capability can mark an opportunity won or lost (the dated opportunity reference lists statecode 1 Won and 2 Lost and states won and lost opportunities are read-only until reactivated) and can reassign it — the update therefore declares transfer at the R3 floor, because the registered PATCH permits ownership reassignment and no reviewed restriction removes it. The WinOpportunity and LoseOpportunity actions — unbound actions accepting an opportunity-close payload (an opportunityclose record bound to the opportunity, plus a status code) — are deliberately not registered, and nothing in this pack creates or deletes any record: record create (POST) and delete (DELETE) are documented in the API and are deliberately not registered. Authentication is OAuth 2.0 client credentials against Microsoft Entra ID: an external deployment process registers an application in the customer's tenant, creates the corresponding application user in the Dataverse environment with a least-privilege custom security role, and obtains access tokens from https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token with grant_type=client_credentials and scope set to the environment URL suffixed with '/.default' (the org URL is the resource). The token endpoint host is deliberately NOT in the egress allowlist: the executor never calls it, because token acquisition and renewal are the external process's job and the injector only injects the stored value verbatim. Dataverse enforces the application user's security roles on every call, so a capability works only if that user is permitted the operation; the registration records the endpoint, not the environment's authorization decision.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/retrieve-entity-using-web-api (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/update-delete-entities-using-web-api (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/use-web-api-functions (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/web-api-basic-operations-sample (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/web-api-service-documents (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/dynamics365/developer/reference/entities/opportunity (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/power-apps/developer/model-driven-apps/clientapi/reference/xrm-webapi/online/execute (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-single-tenant-server-server-authentication (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.