Production scheduling
Which job runs on which line and in what order, when changeovers and due dates disagree.
Dynamics 365 · Optimization apps
Dynamics manages it. We optimize it.
Your ERP records the transaction and enforces the rule. It does not compute the optimal price, the optimal pick path, or the optimal stock level, because that is a data-science question and an ERP is a system of record.
We build the apps that answer it, running in tandem with Dynamics, without touching your ERP core. If you have an implementation partner, they keep their scope.
5
optimization apps in the family
1
in production today, as Paralegent AI
0
changes to your ERP core
The family
Five decisions your ERP does not make
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.
Pricing Optimizer
Working demoPricing & discounting
Dynamics manages
Trade agreements, price lists, discount structures
We optimize
Where margin leaks between list price and invoice, and what the price should have been — from your own transaction history, not last year's spreadsheet.
Used by: The pricing manager
See it in detailPick-Path & Slotting Optimizer
Working demoWarehouse management
Dynamics manages
Bins, locations, inventory, WMS execution
We optimize
Where each item should live, computed from how you actually get ordered, so the trip to fill an order is shorter.
Used by: The warehouse or operations manager
See it in detailContract Review Copilot
In production as Paralegent AIContract / procurement
Dynamics manages
Purchase and sales agreements, contract records
We optimize
MSA and MPA review against your own playbook, with the risky clause found and a replacement drafted.
Used by: In-house legal and procurement
See it in detailDemand & Inventory Optimizer
Working demoSupply & inventory planning
Dynamics manages
MRP, reorder points, safety stock settings
We optimize
The forecast and the safety-stock level per item, so the reorder points the ERP enforces are the right ones.
Used by: The planner or supply chain lead
See it in detailAllocation & Assortment Optimizer
Working demoApparel retail — allocation, size curves, store clustering
Dynamics manages
Assortments, retail category hierarchies, replenishment parameters
We optimize
How deep to go per channel and in which sizes, derived from that channel's own rate of sale rather than a weight typed once and applied to every store in a band.
Used by: The merchandiser or allocation planner
See it in detail
These five run wherever Dynamics 365 carries the transaction and the margin sits in a decision it records but does not compute — most often in manufacturing, retail and distribution, logistics, and financial services. The engineering is the same in each; what changes is which decision leaks the most margin.
Honest status
What exists today, and what we build for you
Worth being plain about this, because vendors usually are not. The Contract Review Copilot is in production today as Paralegent AI; the rest are working demos we can show you on a call. We build each app on request, against your data and your process.
What we will say
- Here is a working demo, on a call, this week
- Here is the data it needs from you
- Here is what we would measure against
What we will not say
- A percentage we have not measured on your data
- A customer count we cannot show you
- That the app is finished before it is
The architecture
Why these run beside the ERP, never inside it
We don’t touch your ERP core. We surround it with intelligence.
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.
Not a report
An optimization app is not a report
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.
What a report gives you
A description of what happened.
- Margin by customer last quarter
- Stockouts by item
- Average pick time by zone
It is accurate, it is useful, and it ends with a person still having to decide what to do — which is the expensive part, and the part that gets deferred when the week is busy.
What an optimization app gives you
A specific recommended value, with the reasoning attached and the constraints already applied.
- This price for this customer.
- This safety stock for this item.
The decision arrives made, and a person approves or overrides it inside the system they already work in.
The process
What building one actually involves
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
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
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
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
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.
Beyond the four
The same pattern applies further
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. These are all decisions an ERP records and does not derive:
Supplier selection
Which supplier gets this order, once price, lead time and reliability pull in different directions.
Assortment and shelf space
How much of the shelf each line earns, and which lines earn none of it.
Replenishment
How much to bring forward and when, so the shelf stays covered without burying cash in stock.
Route planning
Which drops go on which run, and in what order, once time windows and vehicle limits apply.
Collections priority
Which overdue account to chase first, when the team can only work a fraction of the ledger.
Quote win rate
Which quotes are worth the effort, and what to change on the ones that keep losing.
Yield
How much of the input becomes saleable output, and which step in the process is losing it.
Predictive maintenance
Which machine to take offline before it fails, rather than after it already has.
Labour scheduling
How many people on which shift, matched to the work that is actually coming.
Rebates
Which rebate tiers are still within reach this period, and what it costs to reach them.
Anomaly detection
Which transaction does not look like the others, in a volume nobody can read by hand.
Churn
Which customer is quietly drifting away while the account still looks healthy.
Returns
Which returns are worth restocking, and which cost more to process than they recover.
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.
The engineering behind the Optimizers
Read the system of record, compute the decision, write it back behind approval — the mechanism every Optimizer shares.
Your optimizer is only as good as its write path. How should it read and write Dynamics 365?
Microsoft's integration overview for finance and operations apps publishes six integration patterns, and two of those six rows are containers holding several documented surfaces each. This is the map an IT buyer should hold before any companion app touches the ERP — what each surface is for, which limits are actually enforced today, what a read costs versus a write, and the thirteen narrower questions underneath this one.
Read more12 min read
Why does your OData integration slow down at a few thousand records an hour?
Microsoft's own integration sizing examples put OData at a peak data volume measured in records per hour, and the batch data API examples two orders of magnitude above it. Here is the table Microsoft publishes, the caveat it attaches, the validate chain that explains the number, and the four OData behaviours that make a working integration slower or quietly wrong.
Read more9 min read
Which Dynamics 365 service protection limits are actually enforced?
The per-user request ceiling everyone quotes for Dynamics 365 is still published, and Microsoft's own banner says the limits behind it are disabled on all environments with the option to enable them removed. Here is what the service protection API limits page says today, which limit type actually returns a throttling response, the priority control you can set, and why an exemption moves the meter rather than removing it.
Read more9 min read
Why do recurring integrations create duplicate documents?
A duplicated document from a recurring integration is a redelivery, not a lost message. Microsoft documents that an unacknowledged message becomes available to dequeue again every 30 minutes until it is acknowledged, and that the acknowledgement must echo the dequeue response body. Here is the contract in Microsoft's words, the three ways teams break it, one more path that re-serves the same message, one upgrade that breaks your defence against it, and what will not fix any of it.
Read more7 min readBusiness events give you no ordering guarantee. What do you build instead?
Microsoft states it under a heading called Limitations - the order in which Finance and Operations emits business events isn't guaranteed to preserve the order in which they're delivered. The control number is a dedupe key, not a sequence. So you build consumers that are idempotent, derive state from the record rather than the event sequence, and reconcile against the ERP rather than against the event stream.
Read more8 min readWhy do your data events never fire for some entities?
Microsoft names the class exactly - when a data entity uses a view as its primary data source, data events don't trigger. Not all views, not all entities - the entity's primary data source. This article gives Microsoft's wording and its stated reasons, the separate temporary-table case that raises an error instead of staying silent, and the published throughput figures that Microsoft says the environment does not explicitly throttle.
Read more8 min readWhat does dual-write actually cost you in transaction budget?
A budget with three published lines. Microsoft states a two-minute transaction time limit that includes the time to process standard and custom Dataverse plugins, a ceiling of 1,000 records per single transaction in the finance and operations to Dataverse direction, and a plan of record restricting dual-write to a one-to-one mapping. Every dual-write write spends from all three, and the bill arrives at posting time.
Read more8 min readWhy are virtual tables fast in the demo and slow in production?
Because a demo has one entity, few rows and co-located environments, and production has none of those. Across the virtual entities overview, the virtual entities FAQ and the entity-modeling page, the only virtual entity overhead figure Microsoft publishes is for the co-located case; there is an FAQ answer headed "The virtual entity performance is slow when a virtual entity has relationships to other entities"; and Microsoft states that the exemption applies only to the Finance and Operations endpoints the virtual entity plugin invokes, and that because the request is made through the Dataverse API, Dataverse service protection limits might still apply to it.
Read more8 min read
FAQ
Common questions
A companion app that computes a decision your ERP records but does not derive, and writes the recommendation back into Dynamics for a person to approve. Dynamics manages the price list, the bin, the reorder point and the contract record. The app works out what the price, the location, the stock level or the redline should be, from your own history, and hands it back inside the system your team already uses.
A report describes what happened and leaves the decision with you. An optimization app produces the specific value — this price for this customer, this safety stock for this item — with the constraints already applied and the reasoning attached. The work in between, estimating response from history and respecting floors and minimum margins across thousands of items, is exactly the work nobody has time to do by hand.
Neither, and we are not competing for either relationship. Your partner puts Dynamics in and keeps it running. We build a companion app beside it that reads from and writes to documented integration surfaces. The ERP core is not modified, so your upgrade path stays intact and nothing we do creates work for them.
Not off the shelf. A working demo exists for each and we build the app against your systems and your constraints on request. The one exception is the Contract Review Copilot, which is genuinely in production as Paralegent AI. We would rather say that plainly than describe four demos as a shipped product line.
Nowhere. The apps are Dataverse-native, run on Power Platform with Azure for the model workload, and ship via AppSource where that suits procurement. Everything stays inside your own tenancy. For most IT buyers this is the detail that decides it, and it is why we build this way rather than as an outside service with a nightly export.
The decision your team argues about most, provided the history can support it. Pricing is usually the fastest to show something, because every order line carries a price and nothing physical has to change for a better one to take effect. But the honest starting point is looking at your data together — we will tell you when it cannot support the thing you want built.
Start with the decision that costs you most
Tell us which process your team argues about, and we will show you the demo closest to it and what data it would need.