Name: TENSOR
Availability: OnlineOnly

Common Discovery symptoms and questions, their causes, and what to do about each.

Find your symptom or question below. Where a run is involved, read its failure reason in the Run ledger first.

Access and visibility

Symptom or question	Cause and what to do
The Discovery menu entries are missing.	The `discovery_sources` flag is off, or your role has no discovery read permission. Ask your tenant administrator. Tenant administrators themselves hold no discovery permissions by default.
An auditor sees buttons that fail.	Action buttons are permission-checked on the server; the auditor role can read but not decide.
The review inbox says some queues are hidden.	Your role cannot read those queues. A hidden queue is named rather than silently left out. Ask an administrator for the missing permission.
A software, CPE or lifecycle item in the review inbox cannot be decided.	These items are listed but cannot yet be decided in the UI. See Availability.

Sources and runs

Symptom or question	Cause and what to do
Intune shows zero devices although the integration is healthy.	Admin consent is missing or was granted for the wrong Entra tenant. Use Verify Graph access on the Intune onboarding panel.
A source jumped to quarantine.	A run arrived with a scope digest, manifest version, field or data class that was not approved. Read the failure reason, then run a connection test and approve the correct scope.
A run ended as capped.	It would have created or changed more records than the approved maximum. Nothing was written. Check the source, then raise the cap deliberately if the volume is expected.
Retry run is refused.	The run already had three attempts, or its outcome is not retryable (running or succeeded).
There is no button to move a source to active.	Moving a source to active is supported by the service but has no button yet.
Scanner runs do not appear in the run ledger.	The vulnerability scanner source does not yet use the run ledger and commissioning gate. It still pulls all pages and records CVEs.
Failed or partial imports need attention.	They are also raised on Settings → System health. Read the failure reason in the run ledger, then retry the run or fix the integration under Settings → Integrations.

Symptom or question	Cause and what to do
Scanner assets do not become CIs.	By design. A scanner confirms existing CIs and never creates them. Create the CI in the CMDB, or wait for a source that is allowed to create CIs.
Intune devices are not linked to CIs.	Intune pulls and stages evidence, but its observations are not yet linked to CIs by the apply sweep.
Many virtual machines appear as one CI.	They share a placeholder serial number. Discovery filters known filler serials; report any new filler value so it can be added.
The same identity question keeps coming back.	If the CIs are genuinely different assets, choose Mark distinct in the CMDB Reconciliation queue. The decision is remembered and later observations are reported as blocked by split.
Can discovery delete a CI?	No. No discovery permission can delete a CI. Retiring sets the lifecycle state and keeps everything.
Why was a CI not retired although the scanner no longer sees it?	Another origin system still sees it, or not enough complete successful runs have passed. Partial and failed runs never count.

Symptom or question	Cause and what to do
The deviation queue is empty.	Either the estate matches the CMDB or no source has observed it. Check source health and the run ledger.
A deviation cannot be created and is reported as ownerless.	The CI has no technical owner, no business owner and there is no standing queue owner. Set an owner on the CI.
A deviation I resolved with Keep CMDB value came back.	The systems still disagree, so the next run recorded a new deviation. Keeping the CMDB value is only final when you also fix the device or the source.
The attestation shows no independently verified CIs.	Verification needs a second, independent origin system that confirms the CI with authenticated data. One scanner alone can never verify what it discovered. In addition, confirmations are not yet written by the sweep, so the attestation currently shows no verified CIs.
The `discovery_sources` flag cannot simply be switched off.	After the first sealed attestation the flag is sticky. Switching it off needs Request off... and a second person's approval.

Still stuck? Check Sources and commissioning for how the safety ladder behaves, and Availability for what is not yet built.