Complaint and Case Handling That Survives a Regulated Audit

An auditor testing complaint handling is checking four things: that every complaint is uniquely identified at intake, that the record is append-only, that every action and decision is attributable to a named person and a time, and that nothing can be silently edited or deleted. A shared mailbox and a spreadsheet fail all four by design. While a proper system is built, make the mailbox defensible with a numbered intake register, named access, mailbox audit logging and a rule that nothing is deleted. The permanent fix is case management with immutable intake, audited status transitions, a documented retention policy and reporting on time spent in each state rather than total age.

This post describes general practice from 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery, not legal or regulatory advice. Complaint rules differ between financial services regulators, quality management standards such as ISO 9001, medical device regimes and sector ombudsman schemes, and they change. Confirm what your own regime requires, including definitions, response deadlines and retention periods, with your compliance lead, your regulator or your certification body before you design against it.

What is an auditor actually testing in a complaint handling process?

Whether the record can be trusted without trusting the people who keep it. The audit usually samples complaints and walks each one from first contact to closure, asking the same questions every time:

• Unique identification at intake: was the complaint given an identifier the moment it arrived, and can you show that no identifiers are missing, reused or skipped without explanation?
• Completeness: can you prove that every complaint received became a record, including the ones sent to a personal inbox, raised by phone or withdrawn later?
• Append-only history: when something changed, such as the category, the severity or the outcome, is the earlier value still visible alongside the new one?
• Attribution: is every action, decision, reply and status change tied to a named person and a timestamp, not to a shared account or to "the team"?
• No silent edits or deletions: could anyone alter a date, rewrite a response or remove a complaint without leaving a trace?
• Timeliness: can you show acknowledgement and resolution against your commitments, including where the clock legitimately stopped?
• Closure and learning: is the root cause recorded, and do recurring themes feed into corrective action?

Most non-conformities in this area are not findings that complaints were handled badly. They are findings that the organisation cannot prove how they were handled.

Why does a shared mailbox and spreadsheet produce a non-conformity?

Because neither tool was built to be evidence. In a shared mailbox, anyone with access can move, recategorise or delete an email, replies can go from personal mailboxes and never appear in the shared one, and the arrival of a message is not the same as the logging of a complaint. In a spreadsheet, rows can be overwritten, sorted out of order or deleted, dates can be typed rather than captured, and the "last edited by" information describes the file rather than each cell.

The combination adds a reconciliation problem. The auditor sees complaints in the mailbox that are not in the spreadsheet, rows in the spreadsheet with no email behind them, and no way to tell whether the gap is an error or a deletion. Good intentions do not close that gap. Controls do.

What interim controls make a shared mailbox defensible while a system is built?

These controls do not make a shared mailbox a complaint system, but they give the auditor a traceable process and a dated plan while the proper system is delivered. Use this as a checklist:

1. Replace the spreadsheet with a register that numbers itself. A Microsoft List or SharePoint list gives each item a system-generated ID, and version history keeps earlier values of every edited item with the editor and time. An Excel file does neither reliably.
2. Remove delete rights from the register for everyone except a named administrator, and record why any item was ever removed. Closed or invalid complaints are closed with a reason, never deleted.
3. Log a complaint in the register on the day it arrives, before any work starts, and put the register ID in the subject line of every reply so the mailbox and the register can be matched.
4. Grant mailbox access to named people only, remove access for anyone who has left or moved role, and stop replies from personal mailboxes.
5. Confirm that mailbox audit logging is on and that retention or hold settings stop messages being permanently removed. What is available depends on your Microsoft 365 licensing and configuration, so check current Microsoft Purview and Exchange Online documentation with your Microsoft 365 administrator.
6. Agree folders that mean something, such as new, acknowledged, in progress and closed, and never use deletion as a way of tidying up.
7. Record calls, letters and complaints raised in person in the same register, with the channel noted, so the register rather than the mailbox is the complete list.
8. Reconcile weekly: every complaint email has a register entry, every register entry has its correspondence, and exceptions are explained and signed off by a named person.
9. Write the interim procedure down, date it, and keep a short log of when each control was introduced. An auditor can work with a known, controlled interim position far more easily than with an undocumented one.
10. Set a date for the permanent system and report progress against it.

How should intake work so every complaint gets an identifier that cannot be reused?

The identifier should be generated by the system when the record is created, not typed by a person, and the record should be created at the moment of receipt rather than when someone gets round to it.

In Dynamics 365 Customer Service, a case receives an automatically generated case number, and automatic record creation rules can turn an email arriving in a support mailbox into a case, so the email itself becomes the first entry on the timeline. Web forms, portals and phone logging should create cases through the same process, so there is one intake path per channel and no side door. Two design points matter for audit:

• Capture the receipt date and channel as separate columns set at creation and locked afterwards, so a complaint logged late still shows when it actually arrived.
• Decide at design time how a message that turns out not to be a complaint is handled. It should be closed with a reason and kept, because a gap in the numbering is exactly what an auditor asks about.

How do you make a complaint record append-only in Dynamics 365?

Dataverse does not have a single "append-only" switch, so the effect is built from several controls working together:

• Auditing on the case table and on the columns that carry evidence, such as status, category, severity, owner, response dates and outcome, so every change keeps the old value, the new value, the user and the time. Scoping auditing, exporting it to long-term storage and protecting it from deletion are covered in our guide to Dynamics 365 audit trails for compliance, so we do not repeat it here.
• A status history table: one row written for every status change, recording the from state, the to state, the user, the time and a mandatory reason. Security roles grant create and read on that table but not write or delete, so rows cannot be altered by ordinary users once written.
• Controlled status transitions, so a case cannot jump from new to closed without passing through the states your procedure requires. Dataverse status reason transitions, business process flows and server-side validation are the options, and which fits depends on how strict the rule is.
• No delete privilege on cases for agents and supervisors. Administrators can still delete, which is why auditing and a restricted administrator list both matter.
• Corrections as new entries: a wrong category is corrected with a note explaining why, and the audit history keeps the original.
• Customer-facing responses stored as activities on the case rather than typed into a free text field that can be overwritten.

For the people who review individual cases, the free Solzet Easy Audit PCF control shows the audit history on the case form as a readable side panel, with a per-field timeline of how a status or category changed, filters and CSV export. It only reads audit data that auditing has already captured, so it is a way of reading the evidence, not a substitute for turning auditing on or for retaining it.

Why should complaint reporting measure time in each state rather than total age?

Because total age hides where the delay is and cannot show legitimate pauses. A complaint that is sixty days old might have spent most of that time waiting for the customer to send information, which many regimes treat differently from time the organisation spent doing nothing. Total age also cannot show that complaints sit for days before anyone acknowledges them, which is often the first thing an auditor looks for.

The status history table makes the better report straightforward: for each case, the time spent in each state, with states grouped into time the organisation owns and time it is waiting on someone else. Report acknowledgement time, time to first substantive response, time waiting on the customer and time to resolution separately, by category and by team. Where SLAs are used for the same commitments, make sure the pause and resume conditions match the procedure; our guide to SLA timers that pause or show the wrong time covers the common configuration mistakes.

What retention policy does a complaint record need?

A written one, agreed by your compliance lead, that states how long each part of the record is kept, where it is kept, and what happens at the end of the period. The period itself comes from your regime and your legal advice, not from a system default.

• Keep the case, its correspondence, its status history and its audit history for the same period, because a case without its history is not evidence.
• Do not let capacity pressure decide retention. Audit history in Dataverse uses log capacity, which is why a scheduled export to long-term storage is usually part of the design.
• Handle personal data deliberately: complaint records often hold it, and erasure requests have to be reconciled with evidential retention. Our guide to GDPR retention, erasure and DSARs in Dynamics 365 covers that tension.
• Record every disposal: what was removed, under which rule, when and by whom.

Microsoft retention and archiving capabilities for Dataverse have been changing, so check current Microsoft documentation for what your environment supports before you rely on a specific feature.

When is a custom-built case system a better fit than Dynamics 365 Customer Service?

When the Microsoft licensing model or hosting does not fit the organisation, not because Dynamics 365 cannot meet the audit tests. Dynamics 365 Customer Service is usually the faster route when you already run Microsoft 365, have agents who work cases all day and want routing, SLAs and knowledge alongside complaint handling.

A custom-built CRM or case system on React, Node.js, PostgreSQL or .NET can be the better answer when complaint records must be hosted on your own infrastructure or in a specific country, when many occasional users need access and per-user licensing does not scale for them, or when you want an append-only event log designed around your retention rules as the core of the data model. Either way, the four audit tests at the top of this page are design requirements to write into the specification, not features to hope for.

How do you move mailbox history into the new system without breaking the audit trail?

Migrate open complaints as live cases, carrying the original receipt date in its own column and the register ID as a reference, so the numbering of the old process can still be traced. Keep closed complaints in the old register and mailbox, retained and read-only, unless reporting genuinely needs them in the new system. Record the cutover date, and reconcile the count of open complaints in the register against the cases created.

Where the old records have gaps, such as complaints handled in the mailbox that never reached the spreadsheet, do not backfill them as if they had been logged at the time. Our guide to reconstructing records when the evidence was never captured covers how to rebuild what you can and label it honestly. If the new system has to be live before a fixed audit date, building a CRM against a compliance deadline covers the sequencing, and read-only access for external auditors covers letting the auditor sample cases directly.

How does Solzet help build complaint handling that survives an audit?

We start from your procedure and the tests your auditor applies, write them down as requirements, and then design the intake, status model, status history, security roles, auditing, retention and reporting to meet them. We implement it on Dynamics 365 Customer Service, or as a custom-built case system where Microsoft licensing or hosting does not fit, and we can help set up the interim register and reconciliation while the build runs. We do not provide legal or regulatory advice; your compliance lead and regulator or certification body decide what the requirement is. Our senior consultants and full-stack developers deliver remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.