Why can't you price a quote line until you know who is…

Why can't you price a quote line until you know who is asking?

Because in Business Central the price is not a property of the item. It is a property of the relationship, and the relationship is keyed on the customer record.

A customer price group, a contract price, a quantity break, a line discount — every one of them resolves through the customer. Until a request is attached to one, the best any system can do is quote list price, which for a repeat customer is simply the wrong number, and quoting it is worse than saying nothing.

For the owner or sales lead whose quotes go out at negotiated prices. 6 minute read.

Price hangs off the customer record, and Microsoft's own agent shows the mechanism

The clearest description of this dependency comes from Microsoft's documentation of how its Sales Order Agent [GA] calculates a price. The agent does not read a number off the item card. It builds a document:

"The agent creates a temporary sales document behind the scenes and applies Business Central's standard pricing engine, including customer price groups, customer discount groups, and line discount rules. The result reflects the actual price the customer would see on a quote, not the list price from the item card."

Read that last clause again, because it is the whole argument in Microsoft's words: the actual price, not the list price. The difference between them is the customer, and there is no shortcut to it — Microsoft's own agent manufactures a throwaway sales document rather than try to compute the price another way.

Which tells you the order of operations is not negotiable. Identify, then price. A system that resolves items first and identity later has built the steps in the wrong order and will produce list prices for customers who have not paid list in years.

Location is part of the answer too, and it has a fallback chain

Price is not the only thing identity settles. It also decides which stock you are answering about.

Microsoft documents the chain its agent walks before it can check availability at all:

"If a location is assigned to the customer, the agent automatically copies the location code from the Customer Card page to the Location Filter field based on the value in the Customer No. field."

If that field is blank, it falls back to the responsibility centre assigned to the user or customer; if neither applies, it takes the location from Company Information. Three levels, in order, and every one of them starts from knowing the customer.

So an unidentified request cannot be answered on availability either, or rather it can, against the wrong location. That is a more dangerous failure than a missing price, because a wrong availability answer reads as a confident one.

Identity is also what answers "like last time"

Price is the obvious dependency. The valuable one is the order history, and it is the reason identity matters more in this workflow than in almost any other.

A serious share of a distributor's inbound is not a specification at all. It is a pointer:

"Same as the last order for the Kelso site, plus twenty more of the elbows."

There is nothing in that sentence to match against a catalogue. No item number, no description, no attribute. The only place the answer exists is that customer's own invoices and shipments, which means the request is unanswerable until the customer is known — and trivially answerable once they are.

Two things follow that are easy to miss:

The same words mean different products for different customers. "The usual elbows" resolves through history, so it has no fixed answer. A system that learns one meaning globally is building a fault, not a feature.
New customers are the harder problem and the smaller prize. No history, no learned names, no agreed pricing, often no identity either. They are handled, but they should be expected to need a person, and a system that pretends otherwise is guessing on the request with least evidence.

Most of the value in any of this sits with customers you already have. That is not a limitation; it is where the repeat business is.

How identity actually gets established, channel by channel

The confidence you can have in identity varies enormously by how the request arrived, and it is worth being honest about the spread rather than treating identification as a solved step.

Email from a recorded contact — Identified by: The address, against the customer's contacts · How strong: Strong
Portal or EDI — Identified by: A session or trading-partner identifier · How strong: Certain
Email from an unrecorded address — Identified by: Domain, signature block, previous threads · How strong: Fair
A message from a phone number — Identified by: The number, rarely recorded against the customer · How strong: Weak

The bottom row is the one that catches distributors whose customers message them. A personal mobile is almost never on the contact record, so the channel with the fastest response expectation is the channel with the worst identity signal.

Microsoft matches on exactly one field, and explains why

This is the part worth quoting in full, because the restriction looks like a limitation and is actually a security decision:

"For security, the agent identifies contacts exclusively by matching the sender's email address to the E-Mail field on contact cards. It doesn't search by contact name, company name, or other fields when establishing the security context. This restriction prevents unauthorized parties from impersonating a customer by using a similar name."

That is a sound trade and worth understanding before anyone calls it a gap. Fuzzy identity matching on a company name is exactly how you attach one customer's contract pricing to a stranger's request.

The consequences are precise, and Microsoft documents each:

A contact with no email address on file cannot be matched automatically. Microsoft's own advice is to check the field before switching the agent on.
A forwarded message identifies the forwarder, not the original sender — so an internal colleague passing on a customer's email breaks the link.
A phone number cannot identify anyone, because it is not the field being matched.

None of this is a criticism of the design. It is a well-drawn boundary, and knowing where it sits tells you which of your requests will arrive already identified and which will need a person.

Say "unknown", and never guess

Here is our own position, and it is a design choice rather than a documented fact.

A request that cannot be resolved to a customer should be displayed as unresolved, in the queue, alongside everything else — not hidden, not silently attached to the closest-looking name, and not quietly priced at list as though nothing were missing.

The instinct runs the other way. An unmatched row looks like a failure, and failures feel like something to tidy away. But an unidentified sender is the single most valuable row on the screen: it is either a new customer worth having, or an existing one writing from an address nobody recorded. Both deserve a person, and neither survives being guessed at.

A wrong customer is worse than no customer, because every downstream number inherits the error. The price is wrong, the location is wrong, and the quote looks entirely normal.

What happens next is a choice, not an error state

Microsoft handles the unresolved case well, and the way it does is worth copying: it does not fail, it asks. When no contact is found, the reviewer is offered three routes, and the distinction between them is the useful part:

Create a new contact — register the sender permanently. For a genuinely new customer.
Use another contact once — link an existing contact to this task only, "without modifying any master data." Microsoft names the exact case: a forwarded email, or a purchasing assistant writing on someone's behalf.
Update an existing contact's email — permanently, when a customer has changed address.

Three different intentions that a single "match this to that" button would collapse into one. The middle option is the one most systems omit, and it is the one real inboxes need most.

One thing to plan around: the agent "doesn't create new items, contacts, or customers" by itself. A first-time enquiry becoming real business is a human step by design — chapter 10 covers what should be written back at that moment.

About Cognilium Cognilium builds AI systems that work in tandem with Microsoft Dynamics 365 — the decisions the ERP records but does not make. Business Central and Finance & Operations, on your own governed stack. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to know what share of your inbound would resolve to a customer without a person? Book a 15-minute call and we will look at your channels and your contact data together. No deck.

Why can't you price a quote line until you know who is asking?