Are you troubled by strange noises in the middle of the night? Do you experience feelings of dread in your basement or attic? Are fields going missing from your Business Central? Then watch this video:
Have you ever encountered a situation where a user reports that a standard field has suddenly vanished from their Business Central page, while the person sitting next to them can see it just fine? This video dives into a common but maddeningly difficult-to-diagnose issue: the AccessByPermission property on table fields, and how it silently hides fields, actions, and other UI elements based on a user’s security configuration.
The Mystery Begins
Erik has seen this scenario play out at multiple customer sites — particularly at organizations large enough to manage their own security setup and permission sets. The pattern is always the same: a user reports that a standard, out-of-the-box field is missing from their page. It’s not a customization issue. It’s not a personalization problem. The field simply isn’t there.
The specific example that prompted this video was the Quantity Received field on the Purchase Order subform. A user had full access to the purchasing module — they could perform all the actions they needed — but the Quantity Received field had completely disappeared from their view.
Investigating the Page
The first instinct, naturally, is to look at the page definition. In this case, that’s Page 54 — Purchase Order Subform. (A quick aside: the “subform” naming convention is a holdover from the classic client era, when forms were embedded within other forms. Today we’d call it a sub-page, but the AL object names still carry the legacy from 2009.)
Looking at the Quantity Received field on the page, there’s nothing remotely special about it. No visibility conditions, no unusual properties. And the fields right next to it — which look exactly the same in the page definition — were visible to the user. So the page isn’t the problem.
The Culprit: AccessByPermission on the Table
The answer lies not on the page, but on the table. Looking at Table 39 — Purchase Line, specifically at field 60 (Quantity Received), there’s a property that most people overlook:
field(60; "Quantity Received"; Decimal)
{
Caption = 'Quantity Received';
DecimalPlaces = 0 : 5;
Editable = false;
AccessByPermission = tabledata "Purch. Rcpt. Header" = R;
}There it is: AccessByPermission = tabledata "Purch. Rcpt. Header" = R;. This means the user must have direct read access to the Purchase Receipt Header table for this field to be visible. Not indirect access — direct access. If the user’s permission sets don’t grant direct read on that table, the field is silently removed from the UI.
The Double-Edged Sword
On one hand, this is a clever mechanism. It allows Business Central to dynamically show or hide UI elements based on what parts of the system the user actually has access to. If a user doesn’t deal with purchase receipts, why show them the Quantity Received field?
On the other hand, this is nearly impossible to diagnose without access to the source code. There is no indication on the page itself that a field has been removed due to a permission check. There’s no error message, no visual hint, no log entry. The field simply doesn’t exist from the user’s perspective.
It’s Not Just One Field
Staying on the Purchase Line table alone, there are numerous fields controlled by AccessByPermission:
- Expected Receipt Date — requires read access to
Purch. Rcpt. Header - Quantity to Receive — also tied to
Purch. Rcpt. Header - Appl.-to Item Entry — requires read access to the Item table (not the Item Ledger Entry table — the Item table)
- Quantity Received — requires read access to
Purch. Rcpt. Header - Drop Shipment — only shown if the user has direct read access to the
Drop Shpt. Post. Buffertable - Amt. Rcd. Not Invoiced — tied to receipt header permissions
- IC Partner Type / IC Partner Reference — requires read access to the
IC G/L Accounttable - Prod. Order No. — requires read access to
Machine Center
Some of these make intuitive sense. Others are less obvious — like needing access to the IC G/L Account table (rather than the IC Partner table) to see intercompany-related fields.
It’s Not Just Fields
This mechanism doesn’t only apply to fields. AccessByPermission can also control the visibility of actions and other UI elements. Anything on screen can potentially be governed by this property, which makes the debugging challenge even broader.
A Growing Problem
Erik notes that support calls related to this issue have been increasing. Whether Microsoft is applying AccessByPermission more broadly in newer versions of the base app, or whether customers are simply building more sophisticated and granular security configurations, the result is the same: more users encountering mysteriously missing fields.
Key Takeaway
If you find yourself in a situation where a user says “this field is gone and I don’t know why,” your first bet should be to check for AccessByPermission on the underlying table field. Look at the source code for the table (not the page), find the field in question, and check whether it has an AccessByPermission property that requires direct access to a table the user doesn’t have permissions for.
Remember: the permission must be direct, not indirect. This is a critical distinction that can trip up even experienced administrators who believe they’ve granted sufficient access through indirect permission sets.
It’s a simple property with significant consequences — and unfortunately, one that remains invisible without access to the AL source code.
