One email, seven touches — and what Dynamics already does
This is the first of eight rounds on one build I did for a conference session this October: a support mailbox where an email turns into a case, a contact, a grounded reply and an approval — without anyone touching it. I’ll show every step and every number I measured, including the ones I’d rather not. Fictional company, one sandbox, nothing invented.
Before I built anything, I wanted two things to be true: that I knew what the manual work actually costs, and that I knew what Dynamics 365 already does about it out of the box. That’s this round. The flow itself starts in round 2.
Why: seven touches
Walk a support email through a service desk and count what a person does before anyone has replied.
| # | Touch | What it needs |
|---|---|---|
| 1 | Read the email | attention |
| 2 | Find the sender | a search in contacts, often by the address |
| 3 | Create the contact when there is none | name, company, phone from the signature, by hand |
| 4 | Convert the email to a case, give it a title | a decision about what the email is |
| 5 | Write the description | a summary a colleague can act on |
| 6 | Look up the order | another app, another search |
| 7 | Write the reply | the facts from step 6, in the right tone |
Seven touches, and three of them are lookups rather than judgement. That ratio is the whole argument of this series: the lookups belong to a machine, the judgement belongs to a person, and the design question is where the line goes. We will keep returning to it.
How: switch on what is in the box
Dynamics 365 Customer Service takes three of the seven touches out with configuration, no flow. Here is each, as we set it up in the sandbox, with what it did.
1 · Automatic record creation rule: email → case
Microsoft’s docs: Automatically create or update records and the step-by-step Set up rules to automatically create or update records.
Customer Service admin center → Customer support → Case settings → Automatic record creation and update rules → New.
- Name the rule, pick the activity type Email, and the queue that receives the mailbox (ours: Merchant Support).
- Add a rule item: leave the conditions empty for “every email”, choose the action Create case, and map the fields. The modern rule maps Subject → Title and sender → Customer (contact or account) for you, and sets Origin = Email. We added Description → Description.
- Activate. The rule generates a cloud flow named after the rule item — “ARC: … (do not delete or rename)” — with its trigger and its last two steps marked “do not edit”. That generated flow is where the mapping actually lives.
What it did with a known sender’s email: a case, created 27 seconds after our own flow’s case for the same email (more on that below), with the raw subject as the title and the raw email HTML as the description.
What it did with an unknown sender: nothing. The generated flow terminated with “no valid customer found”, because the sender was on no contact or account. A rule can create the contact — the checkbox is “Create cases for email from unknown senders”, and the docs have a small table showing how it combines with the rule owner’s personal option (more on that option below). By default it does not.
2 · Case Management Agent: predict the fields
Microsoft’s docs: Set up Case Management Agent for case creation and update and, for what representatives see, Use Case Management Agent to create and update cases.
Case settings → Case Management Agent → Case creation and update → New rule. Pick the fields the agent fills on a new case — we chose Title, Description and Product — and publish. Two prerequisites that cost us an afternoon: the environment must be on a pay-as-you-go billing plan (Power Platform pay-as-you-go; Power Platform admin center → Billing → Billing plans → the enabled plan → Environments → Add), and the page shows a Pay-as-you-go badge once it is; and in the current wave there is no Activate button, the agent is published.
What it did: 36 seconds after the rule created the case, the agent set Product = Fabrikam Countertop Terminal CT-40 — a real lookup, resolved to the product record, from the words “countertop terminals” in the email. It did not overwrite the raw title or the raw description the rule had mapped; prediction fills what is empty.
3 · Copilot case summary
Microsoft’s docs: Use Copilot-generated case summaries; admins switch it on under Copilot features.
Nothing to configure in our environment: the summary panel was on the case form by default and summarised the email in four sentences — customer, what they received, what they asked, why it is urgent. It is the best of the three on a tense email, and it is read-only: it tells the representative, it does not write to the case.
What we measured
| Native result | Time | |
|---|---|---|
| Known sender, order question | case from the rule; Product predicted by the agent | case at +27 s after our flow’s; Product at +36 s after the case |
| Unknown sender, full signature | no case (“no valid customer found”) | — |
| Same email, rule and our flow both on | two cases for one email | 27 s apart |
The last row is the finding that shaped the whole build. A record creation rule and a flow are each correct on their own; together they watch the same queue and each makes a case, because both fire on the email before either has set it regarding anything. There is no setting that reconciles them. One owner per queue: the rule or the flow creates the case, never both. Round 7 shows the two ways to wire that.
Where it bit us
Twelve days after the measurements above, the evening before the session, I sent a test email from a mailbox that was on no contact — and the flow treated it as a known sender. It took me a while to see why. The address was on a contact that had been created seconds before the flow ran, with the sender’s display name and nothing else: no company, no title, no phone. Nobody on my team had made it.
The author was server-side synchronization, acting on behalf of the user who owns the queue, under that user’s personal option “Automatically create records in Dynamics 365 — Create: Contacts, from the sender or organizer of tracked email messages”. It is on by default for every user in an environment (Set personal options, Email tab). It is a personal setting, not a policy, which means whoever owns a queue mailbox decides it without knowing they did. There is an organisation-wide switch behind it, AutoCreateContactOnPromote in the OrgDbOrgSettings reference — default true — for admins who want to settle it once for everyone.
If you want a flow — or a rule — to decide who an unknown sender is, switch it off on the account that owns the queue: gear → Personalization settings → Email → Automatically create records in Dynamics 365 → Create: off. I also made my preflight check fail when it’s on, so it can’t surprise me twice. To be fair to the feature: for a sales rep tracking their own inbox it’s exactly right. For a service queue it decides who someone is before anyone has looked, on the thinnest evidence there is.
What native did not do, and what the next rounds add
Three things, which are the three objectives of the series:
- Who is writing. The rule needs an existing customer; the personal option guesses from a display name. Round 4 reads the signature with a confidence per field, matches a known person writing from a new address, and creates a contact only when it is sure.
- An answer. Nothing native read the order the email was about. Round 5 reads it through the Dynamics 365 Sales MCP Server from inside the flow, with a deterministic fallback.
- A gate. Nothing native asked a person before a reply. Round 6 is the approval in Teams, the timeout you control, and the audit note on the case.
Everything else — the trigger, the guards, the five prompts, the costs — is rounds 2, 3 and 8.
Try it this week
Thirty minutes in a sandbox: create the rule on a test queue, send one email from an address that is on a contact and one from an address that isn’t, and look at what the rule did with each. Then open your own personal settings and find the Create toggle — I’d genuinely like to know how many of you had it on without knowing. If you run a flow on the same queue, you now know why you’ll see two cases.
Next round: trigger on the email row, not the mailbox — why the flow listens to Dataverse, and the two guards that run before any model.
Lorenc Koka, MD · Senior Delivery Director - Solutions Architecture, D365 CE · Argano
I build governed AI and automation on Dynamics 365 and the Power Platform for enterprise clients, and write down what I learn doing it.
5× FastTrack Recognized Solution Architect Dynamics 365 Customer Engagement · 2022 – 2026