Help

What this is, and how to use it

This system shows what of your products is installed at each of your customers — the Axapta / D365 F&O side and the Dataverse side (CE, Field Service, Project) together, in one place.

A vendor ships a fix against a specific model at a specific version for a specific customer. This exists so that establishing that fact — and noticing when the parts of a product have drifted apart, or when an environment has gone quiet — takes seconds and does not depend on who is in the room.

Start here: the Landscape

Landscape is the front door. Search for a client (or a model / solution name, or a version) and you get the customer's whole estate: environments grouped by their Power Platform container, F&O models and Dataverse solutions side by side, each with its version, the platform version, and how old that fact is.

The grids in the sidebar (Clients, Environments, Packages, …) are for editing and data entry. The Landscape is the read that comes first.

How it works

How your product versions get here

Two channels feed the estate, and the screen tells you which one a fact came from:

  • D365 F&O push (External API)

    A job in the customer's F&O environment posts its installed model versions to this system. This is the F&O side of the estate.

  • Dataverse inventory pull

    For CE / Field Service / Project workloads, the system reads the installed solutions and their versions from Dataverse. This is the Dataverse side.

You can also add or correct anything by hand in the grids.

A vendor product is no longer one piece. A product is defined as the set of components it ships as — for example an F&O model plus Dataverse solutions for CE and Field Service — that are meant to be installed at the same release.

Inside one Power Platform container the Landscape checks whether a product's components sit at the same release and labels it:

Product parts agree
Product parts have drifted
Not enough to compare

A standalone, single-component product is a product too — it is always fully present and can never drift. A product with only half of it installed reads "not enough to compare", never a reassuring "agree".

Each environment is one Dynamics workload:

F&O
Dataverse · CE
Dataverse · FS
Dataverse · Project
Dataverse · Power Apps

The workload is what lets a Dataverse solution be attributed to the right product family. A generic Dataverse container whose workload is unknown is left unknown rather than guessed.

A PPAC environment (Power Platform Admin Center) is the container that holds a customer's cloud workloads — the F&O linked-Dataverse plus CE, Field Service and Project. Grouping the estate by this container is what makes "the parts of this product have drifted" expressible at all: the F&O half and the Dataverse half belong to the same customer landscape because they share the container. On-prem AX boxes have no container and appear on their own — which is normal, not an omission.

"PCM 2.3.1.5" and "PCM 2.3.1.5, last confirmed six months ago" are different answers. Every row says what kind of evidence it rests on and when:

  • reported

    the environment pushed to us — it is alive

  • collected

    we pulled its Dataverse inventory

  • changed

    only a last-modified stamp — which also moves when someone edits a field, so it is not proof the integration is alive

A production environment that has gone quiet for days is an anomaly worth seeing, and the Landscape shows it as one. A failing Dataverse pull is shown with its error, next to the last good inventory — "the pull is broken" and "nothing is installed" are different answers.

Compatibility rules are a curated knowledge base — "product X requires / conflicts with / recommends Y". After a version push the validator re-checks the affected environment and emits warnings you can see against it. A rule can be scoped to a product family; a rule scoped to CE will not fire on an F&O package, and vice-versa.

The grids are where you create and edit:

  • Clients

    the customers you serve; each gets a secret key for the F&O push

  • Environments

    a customer's environments; each is one workload, optionally inside a PPAC container

  • Packages

    the model / solution versions installed per environment

  • Licenses

    license entitlements and their expiry, per environment

Sandbox pool is the internal fleet SUP-ENG reserves for triage — reserve, extend, release, and pull a customer set onto one. Build machines is the internal CI / build-agent inventory (name, MS Core version, hardware, responsible devops). These are internal infrastructure, not customer environments.

A job in the customer's F&O posts to /api/external/update-versions with the client name and secret key. A push that changes nothing still marks the environment as reported, so a healthy-but-stable estate stays green.

POST /api/external/update-versions
X-Client-Name: <client name>
X-Client-Secret-Key: <secret>

{
  "EnvUrl": "https://acme.operations.dynamics.com",
  "EnvName": "PROD",
  "MSVersion": "10.0.42",
  "EnvPackages": [
    { "PackageName": "PCM", "PackageVersion": "2.4.1.7", "PackagePublisher": "sis" }
  ]
}

EnvUrl is the key the system resolves the environment by. Unknown fields are rejected rather than silently dropped.