Enterprise buyers ask for audit and roles the product cannot show
A product that sold well to smaller customers meets larger or regulated buyers who ask who changed what, who may approve what, and how access is controlled. The product cannot show it.
If roles or an audit history were never modelled, no screen can show them, and that part of the product needs rebuilding.
Key facts
- Enterprise buyers asking about audit, roles and permissions the product cannot show is a common signal that a redesign is due.
- Regulated buyers compare the product with a standard, and one gap can end an evaluation.
- For electronic records subject to 21 CFR Part 11 in closed systems, 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails, and record changes shall not obscure previously recorded information.
- When audit logging is introduced later, check for gaps in historical records and validate coverage of required actions from that point on.
- Larger buyers usually involve IT and compliance in the evaluation, and they read the administration screens as closely as the daily ones.
Why it happens
Depth set by early customers. Traceability, audit and roles were built to the requirements of early customers, which were lighter.
An audit trail added late. When audit logging is introduced later, check for gaps in historical records and validate coverage of required actions from that point on.
Permissions used as layout. One layout serves every role with fields hidden by permission. There is no model of who may do what, only of who may see what.
Permission and settings screens were built for the vendor’s own team, and the customer’s administrator cannot use them.
How it shows up
- Prospects in regulated sectors drop out after technical evaluation
- Auditors ask for data assembled by hand
- Security questionnaires take weeks to answer
- Edits overwrite history
- Role changes go through the vendor’s support team
- Operator screens with gaps where fields were removed
Options and trade-offs
| Option | What it involves | The tension |
|---|---|---|
| Complete change history | Every change stored with who, when, before and after | Storage and screens grow with every record, and history views need their own design. |
| Roles with their own screens | Screens per role over shared data | Each role gets a screen built for its job. More screens to maintain. |
| Approval rules | Who may approve what, recorded with the decision | Control increases and every approval adds a step to someone’s work. |
| Depth configurable per customer | Strict settings for regulated buyers, lighter for others | Serves both groups and adds test combinations. |
Building for the strictest regulation raises the bar for every customer and adds steps that unregulated users see as friction.
Common mistakes
- Answering an enterprise requirement with a hidden field or an export
- Adding an audit log that records some actions and skips others
- Treating permissions as a way to hide fields on one layout
- Designing administration screens last
Sources: eCFR, 21 CFR 11.10