Discovery Inbox

    Park automated CI finds for human review before they touch your inventory

    What is the Discovery Inbox?

    Automated discovery sources - Cloud Connectors and the Anzen Discovery scanner - can create or update CIs without human input. The Discovery Inbox sits between those sources and your live CMDB so a reviewer gets the final word on anything ambiguous. Nothing in the inbox changes a CI until you explicitly promote a finding.

    What gets parked

    Three situations land in the inbox:

    • New finds - the discovered resource has no matching CI in your inventory. By default these auto-create as new CIs. Tenant admins can flip the auto-create gate off, in which case new finds are parked here for review and only become CIs when you promote them.
    • Conflicting fields - a CI exists that matches the discovered resource (by external ID for cloud, by IP for the scanner) but one or more provider-owned fields differ from what's stored. These are always parked, regardless of the auto-create setting. Anzen never silently overwrites a CI you've reviewed or hand-edited.
    • Revived deletes - a CI matches the discovered resource but was soft-deleted earlier. Anzen never undeletes silently; the find is parked so you confirm the asset belongs back in your working set. Promote restores the CI and applies the discovered values in one shot.

    The auto-create gate

    Lives in Workspace Settings (tenant superadmins only). Default is on: brand-new finds become CIs immediately, matching pre-feature behaviour. Flip it off when you want every new find to land in the inbox first - useful while you're tuning a connector or running an audit. The setting is per-tenant and stored in the tenant config table.

    Reviewing a finding

    Open a finding to see what's being proposed. The action set depends on the finding type:

    • New: a single Promote button creates the CI from the proposed payload (top-level fields plus interface rows), and a Dismiss button drops the find. Promote stamps the resulting CI's id on the finding so the audit trail links the two.
    • Conflict: each differing field is its own row in the diff table with current and proposed values. Promote and Dismiss act on individual fields - you can accept the new hostname while keeping your manually-set OS info, for example. The row's overall status rolls up to partial (some decided, some still pending), promoted (all decided, at least one promoted), or dismissed (all dismissed).
    • Revive: whole-row decision. Revive clears the matched CI's deleted_at and applies the discovered values; Dismiss leaves it deleted. Per-field on a deleted CI doesn't make sense - the asset is out of your working set, so confirming the revive is the meaningful question.
    • Whole-row shortcuts: the modal footer has Promote-all-pending and Dismiss-all buttons for when the diff is uncontroversial.

    Re-scans don't duplicate

    A partial unique index keys each pending finding to (source, source_connector_id, external_id). When the same scan runs again and re-finds the same resource, the existing pending row is updated in place rather than spawning a duplicate. So the inbox stays a snapshot of what currently needs attention, not a log of every scan.

    Permissions

    Reading the inbox requires ConfigurationItem:read; promoting or dismissing requires ConfigurationItem:update. Toggling the auto-create gate requires tenant superadmin rights.