So approvals can file their evidence records to your own storage, under your own sign-in. We never hold your credentials and never see your data. Written for whoever sets things up at your firm: IT, or a comfortable admin. About 30 minutes. Each step is marked your side or we help.
Rather do this together? Most firms finish in one short screen-share with us.
Email us and we'll set it up with youMost firms should use the flow path: the storage setup guide sets up a no-code Power Automate flow that writes each completed review into your table automatically. Nothing to install, no standing AI instruction, and it is the path we recommend and support first. This guide is the MCP path, an advanced option: it connects Claude directly to your Dataverse via Microsoft's connector program, so your AI files each record itself. Suited to power users who work in Claude all day; be aware the Microsoft connector can be finicky to set up (it sometimes prints its own log text where Claude expects data, which shows up as connector errors). Both paths land the same evidence records in your own table, under your own sign-in.
Why: Microsoft keeps a list of which connector programs may talk to your Dataverse; this enables the standard Microsoft-provided one. Nothing of ours gets installed in your tenant on this path.
https://orgXXXXXXXX.crm.dynamics.com. You'll paste it in step 4.~/Library/Application Support/Claude/claude_desktop_config.json%APPDATA%\Claude\claude_desktop_config.json{
"mcpServers": {
"Dataverse": {
"command": "npx",
"args": ["-y", "@microsoft/dataverse", "mcp", "https://orgXXXXXXXX.crm.dynamics.com"]
}
}
}"preferences" section), every section must be separated by a
comma; a missing comma makes Claude silently ignore the whole file. This exact miss cost us
an hour when we first ran it. If in doubt, email us the file and we'll check it in a minute.This is the one genuinely sharp edge; we hit it ourselves ("lacks a service principal" is its usual error). Microsoft's consent page sometimes stalls, and the fix is a two-line admin command we'll run with your admin on a screen-share; it grants the same consent the stuck page would have. Email us and we'll book 15 minutes.
Run in Azure Cloud Shell as a
tenant admin. It creates the standard tenant-wide consent grant for Microsoft's own
Dataverse CLI client (app id 0c412cc3-0dd6-449b-987f-05b053db9457,
a fixed public Microsoft ID, identical in every tenant):
CLIENT_ID=$(az ad sp list --filter "appId eq '0c412cc3-0dd6-449b-987f-05b053db9457'" --query "[0].id" -o tsv)
RESOURCE_ID=$(az ad sp list --filter "appId eq '00000007-0000-0000-c000-000000000000'" --query "[0].id" -o tsv)
az rest --method POST --url "https://graph.microsoft.com/v1.0/oauth2PermissionGrants" \
--body "{\"clientId\":\"$CLIENT_ID\",\"consentType\":\"AllPrincipals\",\"resourceId\":\"$RESOURCE_ID\",\"scope\":\"user_impersonation\"}"If az ad sp create
says the service principal already exists but you can't see it in Enterprise applications,
that's normal, CLI-created entries are hidden by that portal's filter. The command above
works regardless.
We're building a simpler path: one connector your admin approves with a single click, no config file, no command line, identical setup for every firm, and still nothing of yours in our hands (sign-in and data flow directly between you and Microsoft). Until it passes our own end-to-end testing we don't offer it; the steps above are the honest works-today path.
Where your data goes, plainly: everything this connects reads and writes your Dataverse, in your tenant, as you. The evidence records filed there are yours. Your audit trail stays yours; we never hold your credentials.