What is field level security in Business Central?

Field level security is the ability to control access to an individual field, so a specific user or group can view a field but not edit it, or cannot see it at all, while still working normally with the rest of the record. In Business Central this is not part of the standard permission model. It is a control layer that sits below the permission set, and it has to be added.

The distinction matters because Business Central does offer several features that look like field level security from a distance. Personalization removes a field from a page. Field monitoring emails you when a field changes. The change log records the old and new value. None of these restrict who may change the field. They change what is displayed, or they tell you afterwards what happened.

How the Business Central security model actually works

Business Central applies security in four layers: database, company, object and record. Understanding these layers is what makes the field level gap obvious.

Layer 1: database and environment access

Who can reach the environment at all. In Business Central online this is governed by Microsoft Entra ID. Administrators assign a security group to an environment to decide who may enter it. A user without a Business Central license cannot access the environment even when a member of the assigned group.

Layer 2: company access

Which companies inside the environment a user may open. In a multi company setup this is a meaningful boundary, but it is coarse. A user either works in a company or does not.

Layer 3: object access, which is where permission sets live

A permission set grants access to specific objects: tables, pages, reports, codeunits and more. For table data the access types are Read, Insert, Modify, Delete and Execute. This is the layer most people mean when they say permissions in Business Central. Since the 2024 release wave 2, user groups have been retired and permission sets are assigned through security groups based on Microsoft Entra ID, which lets the same group structure be reused across other Dynamics 365 apps.

Two behaviours at this layer surprise people regularly. First, license entitlements always win. A Team Member user assigned the SUPER permission set is still limited to what the Team Member license entitles, so a permission set can never grant more than the license allows. Second, indirect permissions exist: a user can be allowed to change data only through a specific object, such as a posting routine, and not directly from the user interface.

Layer 4: record access through security filters

Security filters are the closest native equivalent to granular data security. You set a filter on table data inside a permission set, and the user only ever sees the records that match. A salesperson can be limited to their own customers, or a user to one responsibility center. To the user, records outside the filter simply do not exist.

Security filters are genuinely useful, and also genuinely limited. Worth knowing before you build a design on them:

•       Wildcards are not supported. You cannot use * or ? in a security filter. Other operators such as <, >, |, &, .. and = do work.

•       The maximum length is 200 characters, including field names, delimiters, symbols and operators.

•       When several permission sets refer to the same table data, the filters are combined and the least restrictive filter wins. Repeating a table across permission sets that will be combined for one user is therefore risky.

•       Code that needs all records in a table will fail for a filtered user unless the security filtering mode on the record variable is set appropriately, which is a developer decision, not an administrator one.

The key point: layers 3 and 4 answer which tables and which records. Neither answers which fields. There is no permission object for an individual field anywhere in this model.

Why does field level security matter in practice?

The fields that carry the most financial risk almost always sit on tables that many users legitimately need to edit. That is the structural problem. You cannot solve it by removing table access, because the user needs the table to do their job.

The recurring examples in Business Central implementations:

•       Vendor bank account. The classic invoice fraud vector. Anyone who can edit the vendor card can redirect payments. This is also why Microsoft explicitly names the company IBAN as the example field to monitor.

•       Customer credit limit. A sales user raising a credit limit to get an order through the blocking check. Financially material, entirely invisible in a normal workflow.

•       Posting groups on customers, vendors and items. A single wrong general business posting group sends transactions to the wrong general ledger accounts. Correcting it after posting is expensive.

•       Prices, discounts and payment terms. Margin leaks that are hard to detect because each individual change looks reasonable.

•       Dimension values and dimension defaults. Silent damage to reporting integrity that only surfaces at period close.

•       Blocked and status fields. Unblocking a customer or vendor that was blocked for a reason.

The auditor question behind all of these is the same, and it is not "who changed this?". It is "could the wrong person have changed it?". A control that only answers the first question does not close the finding.

What can you achieve with native Business Central features?

Before adding anything, it is worth being precise about what the standard product already does. Several of these features are underused, and in some scenarios they are enough.

Permission sets and security groups

What they do: control which tables, pages and other objects a user can read, insert, modify and delete, assigned at scale through Microsoft Entra security groups.

Where they stop: table level. Modify on the Customer table means modify on every field of the Customer table. There is no way to express "Modify, except the Credit Limit field".

Security filters

What they do: restrict which records a user can reach, which is real record level security enforced by the database.

Where they stop: they select rows, not columns. A user who reaches a record reaches all its fields. Add the 200 character limit, the absence of wildcards and the least restrictive combination rule, and complex designs become hard to maintain.

Page personalization and profile customization

What they do: more than most people assume, which is worth being precise about. Personalization lets a user hide or move fields on their own workspace. Profile customization lets an administrator do the same for everyone assigned to a profile, and it goes a step further: an administrator can use Lock editing to prevent a field from being changed, and a user cannot unlock what the administrator locked. Fields added to a page through customization are always locked and cannot be unlocked at all.

Where they stop: Microsoft is unusually direct about this. The documentation states that the lock editing feature is intended to aid in the accuracy, consistency and reliability of data, and that it is not intended to secure data integrity. In other words, the vendor of the product tells you not to treat it as a security control.

The reasons behind that statement are structural. Locking and hiding operate on the page, while permissions live on the table, so these settings do not follow the data through routes that never render the page. They are also fragile in practice: profiles multiply as roles are added, and the setup is maintained as a list of page customizations rather than as part of your permission design, which makes it hard to review and easy to lose track of.

This is the most common misunderstanding in Business Central field security. Locking a field on a page is a usability measure that reduces accidental edits, and Microsoft says as much. It is not an authorization control, and presenting it as one to an auditor will not hold.

Field monitoring, also called monitoring sensitive fields

What it does: you nominate specific fields, optionally selected by data sensitivity classification, and Business Central logs every change with the original value, the new value, who made it and when. It can email a designated recipient on each change and emit telemetry to Application Insights. Microsoft notes it has significantly less performance impact than the change log, which makes it the recommended option for tracking a limited set of critical fields.

Where it stops: it is a detective control. The change has already happened and the payment may already be out the door. It is valuable, and it belongs in any serious setup, but it does not prevent anything.

Two practical notes that trip people up: after adding fields and starting monitoring, users must sign out and sign in again before the settings apply, and the notification account cannot be the Current User account type or nothing is sent.

The change log

What it does: records insertions, modifications and deletions for the tables and fields you select, including old value, new value, user and timestamp. Microsoft recommends enabling it for tables such as Customer, Vendor, Bank Account, the ledger entry tables and the User and Permission Set tables.

Where it stops: detective again, and this one carries real performance overhead. Logging every change on large tables is a known cause of slowdowns, and the entry volume grows quickly enough that a retention policy is effectively mandatory. If a table is covered by field monitoring, it is not available for change log setup, so the two features are designed as alternatives rather than layers.

Approval workflows

What they do: require a second person to approve a document or a change before it proceeds, which is a genuine preventive control at process level. Microsoft explicitly lists customer credit limit increases and user permission changes as candidates.

Where they stop: workflows act on documents and records, not on individual field edits inside master data. They are complementary to field level security, not a substitute for it.

Custom AL development

What it does: an OnValidate subscriber or a table extension can block a specific field for specific users. Technically this works, and for one or two fields it can be the pragmatic answer.

Where it stops: every field, every rule and every exception is code that must be written, tested, documented and maintained across upgrades. Rules end up living in a repository rather than in a control framework the application manager can review, and each new requirement becomes a development cycle. Auditors also tend to ask for evidence of what the code does, which means the documentation burden never goes away.

Native options compared

The three questions to ask before you design anything

Most field level security projects go wrong because they answer one question when the requirement actually contains three. Separating them makes the design straightforward.

Question 1: who is allowed to change this field?

This is authorization. The answer is a preventive restriction tied to the user or group, enforced regardless of how the data is reached. This is what field level security means in the strict sense.

Question 2: which values are acceptable in this field?

This is data quality and business rules, and it applies even to users who are fully authorized. An authorized purchasing employee can still enter a VAT number in the wrong format, leave a mandatory dimension empty, or set a payment term that violates policy. No amount of authorization control prevents a valid user entering an invalid value.

Question 3: how do we prove what happened?

This is auditability. Field monitoring and the change log answer it, and they should be configured for the same critical fields you restrict, because an auditor typically wants both the control and the evidence.

A complete field level design answers all three. Restricting who may edit the vendor bank account, validating that the IBAN entered is well formed and matches policy, and logging the change for the audit file are three different controls covering three different failure modes.

How 2-Controlware Field Security enforces field level authorization

2-Controlware Field Security is the Business Central app that extends the standard permission structure to field, filter and action level, which is exactly the granularity the native model does not offer. It answers question one.

Three capabilities sit at its core:

•       Restrict editability of specific fields. A field can be made non editable for a user or group while the rest of the record stays fully workable, so the sales user keeps the customer card and loses the credit limit.

•       Apply data filters to limit which records a user can see. Comparable in intent to native security filters, managed inside the same structure as the field rules rather than as a separate 200 character string on each permission set line.

•       Control the availability of actions. Buttons and actions can be made available or unavailable based on permission sets, which closes a gap that fields alone do not cover. Restricting a field is of limited use if the action that recalculates or overwrites it is still available.

The design point that matters most: because the rules extend the permission set rather than the page layout, they follow the authorization structure you already maintain, not the interface. That is what separates a control from a cosmetic change, and it is what allows the setup to be reviewed as part of your normal permission design rather than as a separate list of page customizations.

2-Controlware Field Security is built by 2-Controlware, a Dutch vendor whose origins are in IT audit, and it is available on Microsoft AppSource with a free trial. Organizations that need the same preventive thinking across roles and permission sets, including segregation of duties analysis, typically combine it with 2-Controlware Authorization Box.

Why field level security alone is not enough: the data quality half

Restricting who may change a field does nothing about what value that person enters. This is the half of the problem that most field security discussions skip entirely, and it is where a surprising share of the actual damage originates.

Consider the vendor bank account again. Field level security ensures only the master data team can change it. That is a real improvement. But the master data employee can still enter an IBAN in the wrong format, a number belonging to a different vendor, or a value that fails your internal policy for foreign accounts. The authorization control was correct and the outcome was still wrong.

The same pattern repeats everywhere: a mandatory customer classification left blank, a VAT number that does not match the country format, a dimension code that exists but should never be used on this account type, a payment term that contradicts the agreed policy. Each of these enters the system through a fully authorized user, and each surfaces later as a reporting error, a failed integration or a manual correction.

How 2-Controlware Field Validation closes that gap

2-Controlware Field Validation is the Business Central app that lets you define business rules for your master data, so only data that complies with your rules enters the system and the processes that follow. It answers question two.

Rules are configured rather than developed, which means the application manager can express a policy directly instead of raising a development request. In practice this delivers three things:

•       Preventative quality control. Data issues are stopped at entry rather than corrected downstream, which is where correction is cheapest.

•       Fewer data related support tickets. A large share of "the report is wrong" and "the interface failed" incidents trace back to master data that should never have been accepted.

•       Reliable reporting and integrations. Consistent master data is a precondition for both, and validating at entry is the only point where consistency is cheap to enforce.

Field Security and Field Validation together

The two apps are designed to be complementary rather than alternatives, and the combination is what makes a field genuinely controlled:

Read together, the pattern is simple. Field Security narrows the set of people who can touch the field. Field Validation narrows the set of values they can enter. Native monitoring records what actually happened. Remove any one of the three and a real failure mode reopens.

How to design field level security in Business Central: a practical approach

A workable field level design starts from risk, not from a list of fields. The following sequence keeps the scope controlled and produces documentation an auditor can follow.

1.    Identify the fields that carry financial or compliance risk. Work from your process risks, not from the customer card. Ask where money leaves the company, where reporting integrity is determined, and where a single value changes an outcome. The resulting list is usually far shorter than the first draft, and a short defensible list beats a long aspirational one.

2.    Classify data sensitivity. Business Central includes data classification, and field monitoring can select fields by sensitivity classification. Doing this first gives both your monitoring setup and your restriction design a common basis.

3.    Decide the control type per field. For each field answer the three questions: restrict who, validate what, log the change. Many fields need only logging. A smaller set needs restriction. Being explicit here prevents over engineering.

4.    Map restrictions to your existing group structure. Express rules against the security groups you already manage in Microsoft Entra ID rather than inventing a parallel structure. A design that duplicates your identity model will drift out of date within a quarter.

5.    Write the business rules for the values. Format requirements, mandatory combinations, allowed ranges and policy limits. This is the material for Field Validation, and writing it down often exposes rules that were never actually agreed.

6.    Configure monitoring on the same fields. Use field monitoring for the critical set, given its lower performance impact, and set a retention policy from the start rather than after the log has grown.

7.    Test through every entry route. The page, Edit in Excel, an API call and a configuration package. A control that holds on the page and fails in Excel is worse than no control, because it creates false confidence.

8.    Document the design and the exceptions. Which fields are restricted, for whom, why, and what the approved exception route is. In small finance teams exceptions are unavoidable, and an undocumented exception is what turns into an audit finding.

9.    Review on a schedule. Every new user, permission change, app installation or process change can quietly invalidate the design. A quarterly review is the common compromise, tied to your permission review rather than run separately.

Common pitfalls

•       Treating personalization as security. Covered above, and still the most frequent mistake. Test in Excel before you believe any field restriction.

•       Restricting the field but not the action. If a button recalculates, copies or imports the value, the field restriction is bypassed by design. Action level control is not a nice to have.

•       Relying on the change log for prevention. It is an excellent forensic tool and a poor control. Auditors weight preventive controls more heavily precisely because a log proves the incident happened rather than that it could not.

•       Enabling the change log on everything. Performance impact is real, particularly on large or ledger tables, and an unusable log is functionally the same as no log.

•       Ignoring license entitlements. Entitlements override permission sets. Time is regularly lost debugging a permission design when the actual constraint is the license type.

•       Stacking security filters across permission sets. When permission sets referring to the same table are combined, the least restrictive filter wins. It is easy to build a design that silently grants more than intended.

•       Solving authorization and forgetting validation. The right person entering the wrong value is still a wrong value. Restriction and validation address different failure modes.

Field level security and the audit conversation

For an external accountant or internal auditor, the value of field level security is that it converts an assertion into a demonstrable control. Without it, the honest answer to "can a sales employee change a credit limit?" is "they are not supposed to". With it, the answer is "they cannot, here is the configuration and here is the log confirming no such change occurred".

That difference matters in SOX style control testing, in ISO 27001 access control evidence and in the management letter of a regular financial audit. It also shortens the audit itself, because a configured restriction is testable in minutes while a policy based assertion requires sampling.

The practical recommendation is to pair every restriction with its monitoring. The restriction is the control. The log is the evidence that the control operated throughout the period, which is what testing actually examines.