What it reads, and what it does not.

What it reads

Only what an assessment needs, and only ever by reading:

• Solution and component metadata: which tables, flows, apps, plug-ins, roles and web resources exist, and how they are configured.
• The contents of an exported solution file, where one is supplied.
• Usage and run history, where the connection reaches it: how often a flow ran, how often it failed, how long a plug-in step took.
• The results of Microsoft's Power Apps checker, where it was run.

What it removes

Some things are read in passing and are not kept:

• Secrets found inside a definition are counted, never stored and never shown. A finding says that a secret is present and where, not what it is.
• Credentials for a connection live in Azure Key Vault and are referenced by name. The product database holds no secret of any kind.
• Business data in the tables is not read. The product counts rows; it does not look at them.

What it refuses to do

These are not settings. There is no configuration that turns any of them on:

• It never writes to a Power Platform environment, in any mode.
• It never publishes anything to Azure DevOps, Jira or GitHub that somebody did not select, and it never writes to the environment it read.
• It never shows one engagement's estate to somebody who has not been granted access to that engagement.

What goes into the documents

Three things leave the product, and it is worth knowing exactly what is in each:

• The workbook. Component names, solution names, the findings and their evidence, the estimates and the backlog. Component names are a client's own naming, so treat the file as you would treat their solution export.
• The report. The same material as narrative, plus the list of what could not be checked. Named components appear where a finding is about one specific thing.
• The work items. Titles, descriptions and acceptance criteria, written into the client's own Azure DevOps project, Jira project or GitHub repository. Nothing leaves their tenant that was not already in it.

Deleting an engagement

Deleting an engagement deletes its connections, its runs, its inventory, its findings, its estimates and its backlog, in one operation and without a recycle bin. Work items already published into a client's Azure DevOps, Jira or GitHub are theirs and are not touched.

Where it runs

In Microsoft Azure, in a region chosen for the deployment, in Capgemini's own subscription. The database is reachable only by the product's managed identity; there is no password on it to leak, because there is no password. The one place anything leaves that subscription is Microsoft's own Power Apps checker, where a solution file is analysed in a geography chosen on the connection, and Azure OpenAI, which estimates findings and reads descriptions when a run is set to use a model. That deployment is in the EU data zone and Microsoft does not train models on what is sent to it.

Cookies on this site

This public site sets one cookie, and only if you press the light and dark switch: it remembers which you chose. There is no analytics, no tracking, no third-party script and no font, image or stylesheet loaded from anywhere that would see you arrive. Signing in sets a session cookie, which is what keeps you signed in.