Dynamics 365 Apps
From the field archive · Learned in 2022
Linking Cases to Quotes: Quoting Patterns in Dynamics 365 Customer Service
What I designed when a service team needed to quote from a ticket, and how I'd approach the same problem today.
"Can our service agents send a quote straight from the case?" A partner asked me that in late 2022 while we prepared a demo for a field services company. It's a fair question, and this is a common point of confusion. Service teams live in cases. Quotes live in the sales process. The two don't meet on their own.
In this post I walk through what I found back then, the design I proposed, how I extended it when technicians needed to quote from a work order, and how I'd decide between a custom app, an agent, or the standard Sales quote today.
The core quote model in Dynamics 365 Sales is the same: quotes start as Draft, are activated before they go to the customer, and are either turned into an order or closed as Lost, Canceled, or Revised. Field Service still documents a Case to Work Order business process flow. What's new is the collaboration and AI layer around it. Power Virtual Agents became part of Microsoft Copilot Studio in November 2023, and Customer Service now documents embedded Teams chat and customer support swarming on records. Check current docs for the release status of each feature in your region.
01The gap I found in 2022
The request sounded simple. A customer calls in, an agent opens a case, and the customer asks to add products or services to their contract. The agent wants to send a priced quote without leaving the service context.
When I checked, Customer Service didn't have an out-of-the-box relationship between the case and the quote tables. Quotes are designed to hang off opportunities and accounts. So any "quote from a case" experience was going to be a customization, not a setting.
That's not a flaw. It reflects how the apps were designed. Sales owns pricing, price lists, and the quote lifecycle. Service owns the issue. My job was to connect them cleanly without rebuilding either one.
Before you promise "quote from case," check the table relationships in your own environment. If the link isn't there, plan it as a small, deliberate customization.
02How the standard quote flow works
I always explain the standard flow first, because the custom design should lean on it rather than replace it. According to Microsoft Learn, a quote is created as Draft with revision ID 0. Activating it makes it read-only so your version matches the customer's. Closing it gives you three choices: Lost, Canceled, or Revised. Revising creates a new draft and increments the revision.
| Stage | What happens | Why it matters for service |
|---|---|---|
| Draft | Products, price list, discounts, and taxes are calculated. Prices follow the price list while you edit. | The agent can build the quote while the customer is still on the phone. |
| Active | The quote is locked and ready to send. | Gives you a clean approval point before anything reaches the customer. |
| Order / Closed | An accepted quote becomes an order. Otherwise it's closed as Lost, Canceled, or Revised. | Downstream fulfillment and invoicing keep working as designed. |
When you create a quote from an opportunity, the form is prefilled with the opportunity's products. That convenience is exactly what service teams miss when they start from a case.
03The case-to-quote design
Here's how I approached it. I wrote down the assumptions first, so the business could confirm or correct them. At that point those were only hypotheses.
- Every request starts as a case. No side channels. If the customer asks for more services, there's a ticket.
- The case captures what was requested. The agent records the products or services the customer wants added to their contract.
- A quote is created with those products as line items and linked back to the case through a new, custom relationship.
- The approved quote moves through the standard process to order and invoice, untouched.
The customization itself is small. In Dataverse you add a one-to-many relationship from case to quote, which creates a lookup column on the quote. Add a quotes subgrid to the case form and a simple command or flow that pre-populates the customer and products. Microsoft Learn's guidance on table relationships is worth reading first. It reminds you to check whether an existing relationship already meets the need before you create a new one.
One lookup, not a new table
A case lookup on the quote is enough. Avoid copying quote lines onto the case.
Subgrid on the case
Agents see every quote raised for that ticket, with status, in one place.
Reuse the quote lifecycle
Activation, revisions, and closing work as they do in Sales. No parallel approval logic.
Link, don't rebuild. A single relationship plus a good form gives service teams quoting without forking your pricing process.
04Quoting from a work order
The same partner then raised a sharper version of the problem. Their technicians were already on site, working an existing work order, and needed to send a new quote for extra work.
The flow I described at the time went customer, then opportunity with products, then quote, then back to the opportunity to convert to a work order, then invoice. That's fine for new business. But for a tech mid-job, the only way to get a quote was to go back to the start of that chain. My suggestion was the same pattern as the case: add a direct relationship between quote and work order, and let technicians create quotes from the work order they're standing in.
A field services company wanted to show configurable bills of material and minimum labor charges during quoting. Some of that was true configure-price-quote territory, and some was simply good product setup. The plan was to model minimum labor as a standard product line and treat rules-based component quantities as a CPQ question. In my experience, separating "pricing rules we can configure" from "configuration logic that needs a CPQ engine" saves weeks of debate.
Today, Field Service documents a Case to Work Order business process flow that carries the incident type, description, and functional location from the case to the work order. So the chain is case, then work order, then quote. Each link should be explicit and visible on the form.
05Custom app or agent?
By 2025 the question had changed. Teams asked me whether they should build a quoting app or let an agent handle it. I sketched a simple comparison for a team that was weighing both. I'd still use it today.
| Need | Power Apps quoting app | Copilot Studio agent |
|---|---|---|
| Complex product configuration | Strong | Possible, with effort |
| Structured data entry and validation | Strong | Weak fit |
| Conversational "what should I quote?" | Weak fit | Strong |
| Approvals, workflow, quote documents | Strong | Via flows |
| AI recommendations | Via AI prompts or tools | Built in |
| Reach in Teams, web, and Copilot | Limited | Strong |
What I recommend: the app (or the standard quote form) owns the record and the rules. The agent sits in front, answers questions, suggests products, and calls a flow to create a draft quote. A human activates it. I cover this split in more depth in Copilot Studio, Power Apps, Power Automate or Pro-Code? A Simple Decision Guide.
Let the agent draft. Let the app, and a person, approve. Pricing that reaches a customer should pass through a locked, auditable step.
06Collaboration around the case
Not every case-centric request is really about quoting. Sometimes it's about getting the right experts on a hard case and recording what they decided.
A large technology services company kept its CRM on another platform but wanted Teams to be the place where experts swarmed on complex cases. They wanted to pull case details into a channel, collaborate, and push only the final findings back. I tested the core of it and proposed three parts: a cloud flow to fetch the case and create the channel, Dataverse to track each request for reporting, and an agent that could post a clean summary back to the CRM. The hard part wasn't the plumbing. It was deciding what to send back. The full chat is noisy. The findings are what matter.
If your cases already live in Dynamics 365 Customer Service, check the documented collaboration features before you build: embedded Teams chat linked to records, sharing records into Teams conversations, and customer support swarming that suggests experts based on skills. I'd temper expectations on swarming until you confirm its release status and licensing for your tenant.
Whatever you build, it should sit inside the right environment with the right data policies. My post on environment strategy and DLP covers how I set that up, and the governance toolbox covers how I track what gets built.
07Checklist before you build
- I've confirmed which table relationships already exist between case, work order, and quote in my environment.
- The business has agreed the assumptions: every request is a case, and the case records what was asked for.
- The custom link is a single lookup, added in a solution with a publisher prefix.
- Quotes still follow the standard Draft, Active, and close or order lifecycle.
- I've separated configurable pricing (price lists, discounts) from true CPQ configuration logic.
- If an agent is involved, it creates drafts only, and a person activates the quote.
- Collaboration needs (swarming, Teams chat) are scoped separately from quoting.
- The solution is placed in a governed environment with agreed data policies.
Where I'd start
Pick one real request type, like "add a service to my contract." Walk it from the first call to the invoice and mark where the agent or technician gets stuck. If the gap is the missing link between case or work order and quote, add the relationship and a subgrid, and keep the Sales quote lifecycle as is. Add an agent only once the record and the approval step are solid.
Happy to go deeper on any of this.
— K.G
← Read "Copilot Studio, Power Apps, Power Automate or Pro-Code?"
Sources
- Microsoft Learn: Manage quote, order, and invoice (Dynamics 365 Sales)
- Microsoft Learn: Create or edit quotes in Dynamics 365 Sales
- Microsoft Learn: Create a work order from a case (Dynamics 365 Field Service)
- Microsoft Learn: Create a relationship between tables by using a lookup column; Create one-to-many or many-to-one table relationships in Microsoft Dataverse overview
- Microsoft Learn: Overview of collaboration in Dynamics 365 Customer Service; Configure customer support swarming for complex cases
- Microsoft Learn: Copilot Studio overview
- Microsoft Copilot Blog: Microsoft Power Virtual Agents, now part of Microsoft Copilot Studio (November 2023)
Get new posts by email
Provider: your email provider
