What it does

Record creation and update rules (everyone still calls them ARC rules) turn incoming activities into records — usually an email landing in a queue mailbox becoming a case. Each rule watches a source activity type, evaluates a set of ordered rule items, and runs create/update actions on the first item whose conditions match.

Key facts

• Configured in the Copilot Service admin center (the app formerly called Customer Service admin center) under Case settings > Automatic record creation and update rules. The old Customer Service Hub settings area is still where some tenants land, and the two views don't always show identical fields.
• Supported source activity types out of the box: email, social activity, task, phone call, appointment, service activity, and custom activities. The target can be any system or custom table, not just Case.
• Email rules must be tied to a queue. For every other source type the queue is optional, and you can have at most two active rules — one with a queue and one without.
• Since July 2025 a single rule can be associated with multiple queues, so the old pattern of cloning one rule per shared mailbox is no longer needed.
• Email-specific conditions on the rule header: create records for unknown senders (which also creates a contact), create a case only if the customer has a valid entitlement, allow creation for activities linked to an already-resolved case, and a time threshold for how long ago that case was resolved.
• Auto-acknowledgement is built in: Send automatic email response to customer on record creation plus a template selection. You do not need a separate flow for a simple "we've got it" reply.
• A rule item can contain exactly one Create record step. Update, send email and start child workflow steps can be layered on top, but a second create in the same item is not allowed.
• Conditions can't be built on Option Set or Two Option columns directly — they're only usable as string comparisons. Plan condition columns accordingly.
• Activating a rule generates a backing process/flow. You can't edit an active rule; deactivate, change, reactivate.
• The modern rules experience isn't supported on-premises.

When to use / skip

If the client takes support requests by email — and nearly all of them do — you're using this. It's the cheapest, most predictable way to get an email into a case with the right customer, queue and origin set. Reach for a hand-built Power Automate flow only when the logic genuinely exceeds what a rule item does: multi-record creation, calls to external systems, or branching that would need five rule items to express.

Skip it for channels that aren't activities. Anything arriving through a messaging or voice channel is handled by that channel's own configuration, not by ARC. And don't use ARC to bulk-convert historic activities; the retroactive apply path exists but is a developer operation, not something you talk a client through.

Configuration decisions

• One rule per queue versus one rule associated with several queues. The multi-queue option is simpler to maintain but means one shared condition set — split rules when the business rules per mailbox genuinely differ.
• What happens to replies on closed cases: create a fresh case, or reopen the existing one. If reopening, decide the resolved-since window and accept that reopening needs a flow, not a rule action.
• Whether unknown senders get a case at all. Creating contacts automatically keeps agents unblocked but quietly fills the contact table with noise from newsletters and bounce messages.
• Whether case creation is gated on an active entitlement. Powerful for contract-driven support, and a support-desk outage waiting to happen if entitlements aren't kept current.
• Field mapping on the create step: title, customer, origin come out of the box; subject, priority, case type and the owning queue are the ones you'll actually be asked for.
• Auto-response on or off, and which template. Watch for loops with the customer's own autoresponder.

Gotchas

• Deactivating or deleting a rule does not always stop cases appearing. The backing child flow can stay switched on and keep creating records; you have to turn that flow off in Power Automate as well.
• If the incoming activity already has a Regarding record of a different table to the one in your create step, the process silently doesn't run. No error, no case — just nothing.
• Email bodies are HTML. Mapping the body into a plain-text column drags markup with it unless you strip it, and the common regex fix permanently removes the tags from the mapped value.
• Rule item order matters and is evaluated top down, first match wins. A broad catch-all item sitting above a specific one makes the specific one dead code.
• Deactivate rules before a solution import or upgrade and reactivate afterwards. Importing over active rules is a reliable way to end up with duplicated or orphaned backing processes.
• Rules created or edited on modern versions can't be exported backwards to older releases — relevant only on long-lived legacy tenants, but it does bite during migrations.

Consultant notes

• Demo the failure case, not the happy path. Show what happens to a reply on a resolved case and let the client choose the behaviour; it's the single most argued-over rule in UAT.
• Check the queue's mailbox is approved and tested before you blame the rule. Most "ARC is broken" tickets are server-side sync problems.
• Tell the client that auto-response templates are customer-facing copy and need signing off by whoever owns tone of voice — it's usually the first thing anyone external sees.
• Before go-live, send test mail from an unknown external address, a known contact, and a reply on a resolved case. Three emails, and you've covered nearly every branch.
• Push back on requests to add elaborate branching inside rule items. Past three or four items, a proper flow is easier to support and far easier to debug.

---

Worth another look if Microsoft moves more of this into the agent-driven case creation experience, or if multi-queue rules pick up per-queue overrides.