Who viewed that record? The read-access gap in Dynamics 365 F&O

Finance & Operations tells you who changed a record. It does not reliably tell you who looked at one, and for payroll, pricing, and customer data that is the question auditors actually ask.

Change tracking answers only half the question

Database logging records writes: who edited a vendor bank account, who changed a price. That is genuinely useful, and it is where most F&O control conversations stop. But the sensitive-data questions an auditor or a privacy regulator asks are usually about reads. Who pulled the payroll table? Who opened that customer's record the week before they were approached by a competitor? Standard Finance & Operations has no dependable answer.

Why teams discover this late

The gap tends to surface during an audit, a data-subject request, or an investigation, which is the worst possible moment. Reconstructing read activity after the fact means trawling infrastructure logs that were never designed to answer a business question, and that usually cannot distinguish a user opening a form from a batch job touching the same table.

Approvals that resume where the change happened

The related failure is workflow. Native F&O workflow restarts at the top when a record changes, so a single late edit throws away every approval already collected. Field-level change approval that resumes at the change, rather than restarting the document, is what makes controls survive contact with how people actually work.

Controls belong in the transaction, not beside it

A control enforced by a nightly report is a control you find out about tomorrow. Enforced in the transaction, it simply cannot be bypassed, and posted records stay immutable. That, plus a tamper-evident record of both changes and views, is the difference between believing your controls hold and being able to show it.