It Worked for the Consultant. Will It Work for the User?
A Business Central customization can work perfectly for the person who built it and still fail for the person it was built for. The difference is often not the code. It is the permissions.
Consider a warehouse user opening a page that a consultant has tested successfully. The page itself may be fine. The problem may only appear when the user tries to post, open a related record or trigger an action that touches a table their role cannot access. From the consultant's account, the entire process looked complete. From the user's account, it stops halfway through.
These are frustrating defects because they can survive apparently thorough functional testing. The behavior was checked, but it was checked from the wrong point of view. In Business Central, permissions are not a small technical detail around the edge of the process. They help determine what the process actually is for each user.
The same principle applies to excessive access. A test should not only establish that a finance clerk can complete the work assigned to that role. It should also avoid relying on permissions the clerk should never have. Otherwise the easiest way to make a test pass can accidentally become the wrong way to make the business process work.
As teams produce changes more quickly, this kind of realism becomes more valuable. Nobody benefits from accelerating a customization through development only to discover on release day that the intended users cannot complete it. Testing in the right user context is one of the ways speed becomes dependable rather than merely impressive.
Developers and consultants commonly work with broader access than warehouse, finance or sales users. A process that succeeds under elevated permissions has not yet proved that the intended user can complete the same work with the role they actually hold.
The reverse matters too. Good testing should not only show that a user can do what their role requires. It should also give confidence that they cannot do what the role is meant to prevent.
This issue predates AI-assisted development. What changes with faster generation is the volume of change that can reach review. A familiar gap can therefore appear more often unless realistic permissions are part of the evidence from the start.
That makes permission-aware testing a governance question, not a finishing touch. Before a change reaches production, a partner should be able to say which user context was tested and what that test proved.
"It worked for me" is useful during development. It is not the standard a customer should have to rely on.
Permission issues are also a useful example of why code review alone cannot carry the entire assurance burden. A reviewer can read an object carefully and still not reproduce the effective access of every role involved in the business process. Some questions are best answered by executing the behavior under the conditions that matter.
This is especially relevant in processes that cross departments. A sales user may initiate something that a finance user completes, while a warehouse user needs access to only one part of the same record. Testing each step with broad access can hide the very boundaries the customer's security model was designed to enforce.
The lesson is not that every possible role combination needs exhaustive manual testing. It is that the intended user context should be explicit enough to form part of the evidence. When a test passes, the team should know whose experience that pass represents.
That is a more useful standard than simply increasing the number of tests. Ten tests under the wrong access can provide less confidence than a smaller set that reflects the people who will actually perform the work.