INSPECTOR METHOD · EVIDENCE BEFORE ASSERTION

A CRM finding should tell an operator what fired, where to look, and what the scan could not see.

Inspector is a modular Dynamics 365 operator toolkit. It runs named, read-only checks from the browser session already in use, shows results locally without an account, and lets the operator decide whether to save a minimized result to Anselith.

This page describes the public beta available now. CPQ and the roadmap concepts shown in Labs have different methods, data paths, and availability.

01

The evidence-first workflow

Current public-beta behavior
  1. 01

    Start from the operator's existing boundary

    Inspector sends GET requests through the Dynamics 365 session already open in the browser. It does not create an app registration, introduce a service identity, or widen Dynamics permissions. Restricted-role acceptance remains an explicit public-beta validation item.

  2. 02

    Run named, bounded checks

    Each current tool checks a defined structural condition in pipeline, hierarchy, activity, contactability, or schema metadata. Inspector does not turn those checks into a prediction or a generic claim that the CRM is clean.

  3. 03

    Show the result locally first

    The operator can review the scan summary without creating an Anselith account. Returned record examples and Dynamics deep links keep the result close to the system where remediation actually happens.

  4. 04

    Disclose incomplete coverage

    Permissions, unsupported schema, query limits, or a failed check can make a scan incomplete. That boundary belongs in the result; an incomplete scan must not be presented as proof that the inspected environment is healthy.

  5. 05

    Save only when the operator chooses

    A local scan does not require an Anselith account. Saving is a separate, explicit step; the service reconstructs a strict allowlisted projection for the signed-in operator's workspace and never writes changes back to Dynamics.

  6. 06

    Separate product from roadmap

    Inspector is the sole public-beta product. CPQ is a separate private beta in Labs. Other product families and shared experiences are planned concepts or synthetic previews, not connected customer workflows.

02

What an explainable result carries

Reviewable by design
01

Origin

Which source record, document, event, or calculation supplied the fact.

02

Scope

Which tenant, operating object, population, and permission boundary the result covers.

03

Method

The check, formula, threshold, or policy used to reach the result.

04

Time

When the evidence was observed and, where supported, the record state at that point in time.

05

Authority

Who can review, approve, or execute the next action.

06

Status

Whether the capability is live, in beta, an interactive preview, or still planned.

03

Keep current product and Labs separate

Availability is part of the claim

Anselith Inspector

Free public beta

A local, read-only finding identifies the check that fired and returns sample Dynamics record pointers where supported.

CPQ

Separate private beta

Invited CPQ users can create deterministic quotes and route the current discount approval. CPQ is not part of the free Inspector scan.

Roadmap product families

Planned / synthetic

Relationship, contract, revenue, and platform intelligence pages describe possible future workflows; preview values are synthetic and are not customer results.

Assistant and Executive Command

Planned experiences

These concepts show how future modules could be composed. They are not production assistants, reporting products, or connected executive dashboards today.

Inspector findings, a CPQ approval, and a synthetic roadmap preview answer different questions. They are not one connected suite workflow today and must not share an implied level of production readiness.

WHEN THE EVIDENCE STOPS

Uncertainty is part of the result.

Operational systems contain incomplete relationships, stale states, partial permissions, and contradictory dates. The correct response is to disclose the boundary and create a reviewable exception—not to manufacture a cleaner conclusion.

  • Do not convert fixed review-priority labels into a predicted business-impact score.
  • Do not hide conflicting source records behind a single clean-looking answer.
  • Do not present an inference as a source fact.
  • Do not present synthetic preview data as a customer result.

Inspect the operating contract

Run a useful scan before you adopt a platform.

Start with the free Inspector beta, or review every current tool and its boundary first.