What it does

Resolving a case writes a Case Resolution activity against the case and flips the case state to Resolved. The dialog the agent fills in on the way is configurable: a minimal two-field prompt by default, or a form on the Case Resolution table you can customise with your own columns.

Key facts

• The minimal resolve dialog is the default and shows only Resolution Type and Resolution. Billable Time, Total Time and Remarks are not on it.
• Two levers control the experience. In the Copilot Service admin center, Case settings > Other settings > Service Configuration Settings has a Resolve case dialog option of Standard dialog or Customizable dialog. Separately, the Enable minimal case resolution dialog setting definition can be set to No to get the older experience back, and that only takes effect when the admin centre option is on Standard dialog.
• The customisable dialog renders a main form on the Case Resolution table, edited in Power Apps like any other form. Environment-level settings can be overridden per app.
• Billable Time only calculates automatically if Total Time is also on the dialog. Add one without the other and the client will report it as a bug.
• Adding the Regarding field to the case resolution form breaks resolution outright — agents get an error when they try to close a case.
• Custom resolution values must exist twice: as a choice on the Case table's Status Reason column and as a choice on the Case Resolution table's Resolution Type column, with the identical numeric value. Mismatch and the value silently won't appear.
• Cases can only be resolved through the Resolve Case command. Setting the status field directly on the form or in a grid doesn't work.
• Open activities on the case raise a warning with a count and a link. The agent can confirm and have all open activities cancelled automatically as part of resolution. A setting definition lets you redirect that link to a named tab on the form.
• Cancelling a case requires all case activities to be closed first, and the confirm dialog asks for Canceled or Merged as the status.
• Once resolved or cancelled, case columns are read-only in the UI. They can still be updated through the API or a Power Automate flow.
• Using the customisable dialog needs read on Environment Variable Definition for agents, and create/read/write for the manager role. Custom security roles have to be updated or the dialog fails for those users.

When to use / skip

The default minimal dialog is right for most implementations: two fields, low friction, agents actually fill it in. Move to the customisable dialog when the client needs structured close data — billable minutes, a root-cause code, a resolution category feeding reporting — and is willing to accept that every extra mandatory field is a few seconds on every close and a reason for agents to pick the first value in the list.

Don't use the resolution dialog as a mini survey. If someone wants eight fields at close, ask what report they're building and whether those values could be set earlier in the lifecycle instead, when the agent knows them and isn't trying to end a call.

Configuration decisions

• Minimal, standard or customisable dialog, and whether any override is applied at app level for a subset of agents.
• Which close columns are mandatory. Root cause and resolution category are the usual two; time tracking is the one to challenge.
• Whether Total Time and Billable Time are surfaced at all, and if so, whether the client's billing process actually consumes them.
• The list of resolution types, and the discipline for keeping Case status reasons and Case Resolution resolution types in step across environments.
• What happens to open activities on close — auto-cancel on confirm, or block agents until they tidy up.
• Whether resolved cases can be reopened, by whom, and whether that's manual, an ARC rule with a flow on inbound email, or not at all.

Gotchas

• The Regarding field on the resolution form is a hard failure, not a cosmetic issue. It's the most common cause of "we can't close cases" after a customisation pass.
• Custom resolution type values added on only one of the two tables just don't render. No error is shown to the maker.
• Resolved cases going read-only surprises clients who expected agents to correct a typo afterwards. The workaround is a flow that reactivates, edits and re-resolves, which then writes a second Case Resolution record.
• Every resolve and reactivate cycle leaves another Case Resolution activity on the timeline. Reporting that counts resolutions rather than cases will overcount reopened work.
• Auto-cancelling open activities on resolution can quietly kill scheduled follow-ups the agent still needed.
• Parent and child settings override individual behaviour: with the closure preference set to block, agents can't resolve the parent no matter what the dialog offers.

Consultant notes

• Ask early whether anyone will ever read the resolution notes. If the answer is no, keep the minimal dialog and spend the effort elsewhere.
• Demo close-with-open-activities during UAT. It's the moment clients discover what their agents leave lying around on cases.
• If time tracking is requested, get the client to state the downstream process — invoice, chargeback, capacity model — before you enable it. Usually nobody owns it.
• Check the resolution dialog under every security role before go-live, not just as admin. The environment variable privileges catch out custom roles.
• Agree the reopen policy in writing. "We'll just reopen it" is a design decision with reporting consequences, not a detail.

---

Worth another look if the client starts billing from case time, or after any release wave that touches the resolve experience.