Dynamics manages it. We optimize it.

Each app is named for the decision it optimizes. Each one sits beside a Dynamics module that already manages the process well, and takes over the one part the module was never built to do.

Worth being plain about this, because vendors usually are not. Three of the four exist as working demos we can show you on a call. One, the Contract Review Copilot, is in production today as Paralegent AI. We build each app on request, against your data and your process.

An optimization app that modifies the ERP core is a liability: it complicates every upgrade, and it puts us in your implementation partner’s way. So these are built on the stack you already govern, Power Platform, Dataverse and Azure, reading from and writing to documented integration surfaces. Your partner keeps their scope. Your upgrade path stays intact. And the decision itself stays with the person who owns the process, because the app produces a recommendation and the evidence for it, not an instruction.

This is the question we get asked most, usually phrased as “don't we already have that in Power BI?”. The honest answer is no, and the difference is not sophistication — it is what lands on the desk.

The distinction matters because the work that produces the recommendation — estimating response from history, applying floors and minimum margins, choosing a service level — is the work nobody has time to do by hand across thousands of items. A report hands that back to you. An app does it and shows you what it did.

Every one of these follows the same four steps, whichever decision it optimizes. The order matters: we look at your data before we agree to build anything, because the answer is sometimes that we should not.

1. 1

   Name the decision

   Not the process — the decision inside it. Not "improve pricing" but "what price should this customer see for this item today". If it cannot be stated as a question with a single answer, it is not ready to optimize.

2. 2

   Test whether the history can answer it

   Pull the relevant history and check whether it contains enough variation to learn from. This is where engagements stop, and stopping here is cheap. A recommendation derived from history that cannot support one arrives with the authority of arithmetic and none of the reliability.

3. 3

   Build on your stack, inside your tenancy

   Power Platform and Dataverse, with Azure for the model workload, shipped via AppSource where that suits procurement. We read and write through documented integration surfaces. The ERP core is not modified, so your upgrade path and your implementation partner's work are untouched.

4. 4

   Hand the decision to its owner

   The recommendation lands in Dynamics where the pricing manager or planner already works, with the reasoning visible. They approve or override. Automatic application, for defined segments only, is something you move to later — after the recommendations have been right long enough to trust.

The four above are where we focus, because depth beats breadth and we would rather be genuinely good at four things than plausible at twenty. The pattern does extend: production scheduling, supplier selection, assortment and shelf space, replenishment, route planning, collections priority, quote win-rate, yield, predictive maintenance, labour scheduling, rebates, anomaly detection, churn and returns are all decisions an ERP records and does not derive. If yours is one of those, the conversation is the same one. Start it and we will tell you honestly whether it is a fit.