Every support team I have ever met has, at some point, run its entire operation out of a shared mailbox called something like support@company.com. Someone “keeps an eye on it.” Urgent emails get flagged, less urgent ones get folders, and at least once a quarter a customer’s message sits unread for four days because the person keeping an eye on it was on vacation. The inbox is many things, but it is not a ticketing system — and Dynamics 365 has had the fix built in for years.
In this post we will set up automatic record creation in Dynamics 365 Customer Service: a rule that watches a support queue and turns every incoming customer email into a case, automatically, with no code and no one keeping an eye on anything. It pairs naturally with the SLAs and entitlements we built over the last two weeks — a case that creates itself at 2 a.m. starts its first-response clock at 2 a.m., which is exactly the point.
Why the Usual Approaches Fall Short
The shared-mailbox approach fails for a reason that has nothing to do with effort: an inbox has no state. An email is either read or unread — there is no “in progress,” no owner, no priority, no SLA, no history once someone deletes it. Every process your team runs on top of an inbox is held together by discipline, and discipline does not scale and does not take vacations.
The engineering-minded team’s next move is a custom Power Automate flow: trigger on new email, create a case, done in an afternoon. It works — until the edge cases arrive. Reply threads spawning duplicate cases. Out-of-office auto-replies creating cases about cases. Unknown senders failing the customer lookup. You end up owning a small product. Automatic record creation is Microsoft’s first-party answer to exactly this problem, with the edge cases — threading, sender resolution, loop protection — already thought through.
Prerequisites
- Dynamics 365 Customer Service and access to the Copilot Service admin center.
- A queue for the support mailbox. In production this queue has a real email address with server-side synchronization approved by your Exchange admin; in my sandbox it is a demo queue called Support Inbox (Demo).
- A sandbox to practice in, as always.
Step 1 — Give the Emails Somewhere to Land
Automatic record creation watches a queue, not a mailbox, so the queue comes first. Under Customer support > Queues, create one for the support address. The production wiring — mailbox, server-side sync, Exchange approval — is its own topic, but the principle is simple: emails to support@ arrive as email activities in this queue, and the queue is what the rule will monitor.
Step 2 — Create the Rule
In the admin center, go to Customer support > Case settings, find Automatic record creation and update rules, and select Manage, then New. Step one asks four questions: a Rule name, the Queue scope (track a single queue), the Activity type to monitor (Email — though conversations, custom activities, and others are options), and the Queue to monitor. Save, and the rest of the form wakes up.
Step 3 — Tell It What to Do
Step two of the form holds the actual logic. Select New to add a rule item, and you get a condition builder: a name, a condition that must pass, and the action to take. Two things worth noticing. The condition can be left blank, which means every email qualifies — the right default for a support mailbox, where the whole point is that nothing slips through. And the Record to create is already set to Case, with a note that the heavy lifting is generated as a Power Automate flow behind the scenes — you can open that flow and enrich the case (set priority from keywords, route by customer tier) if you outgrow the defaults.
Step 4 — Activate It
Select Activate and read the dialog before you click through it: only one rule per queue and activity type can be active — activating this one deactivates any predecessor. Confirm, and the rule goes read-only with an Active status, a Flow menu appears over the rule items (there is the generated Power Automate flow, in plain sight), and the Activity monitor tab starts logging every email the rule processes — your first stop when someone asks “why didn’t that email become a case?”
⚠️ Important: a case needs a customer, and the rule resolves one by matching the sender’s email address to a contact or account. Decide up front what happens when a stranger writes in: on the rule’s Advanced tab you can have it create a contact automatically for unknown senders, or skip case creation entirely. Choose deliberately — auto-creating contacts keeps coverage at 100% but invites junk records from newsletters and bots, while skipping unknown senders silently reintroduces the exact gap you built this rule to close.
Limitations and Good Habits
- Replies do not spawn duplicate cases. An email in an existing tracked thread lands on the original case instead of creating a new one — that is the threading logic you did not have to write.
- Beware the auto-reply loop. If you enable Automatically reply to email in step three, your acknowledgment can meet the customer’s out-of-office in an infinite polite standoff. The platform has protections, but test with a real mailbox before trusting them.
- Use the Activity monitor, not guesswork. Every processed email is logged with what the rule did and why. When something does not become a case, the answer is in the monitor, not in a meeting.
- Resist rebuilding the flow from scratch. The generated Power Automate flow is editable, and light enrichment is fine — but the further you drift from the generated shape, the more upgrade friction you own. Extend, don’t rewrite.
Closing Thought
A support inbox without automatic record creation is an airport where the bags are handed out on the tarmac — whoever shouts loudest gets theirs first, and nobody notices the suitcase left behind until its owner files a complaint. The rule is the baggage carousel: unglamorous, entirely mechanical, and the reason every single bag comes around where someone can claim it. Build the belt once, and stop paying people to remember luggage.
