Control Editability

Editability control allows you to make fields read-only for specific users. Users can see the field value but cannot modify it. This guide explains how to configure and use editability settings.

Understanding Editability

When a field's editability is set to "No":

The field appears on the page
The user can see the value
The field is grayed out or shows as read-only
Clicking the field does not allow editing
Keyboard input is blocked

When to Use Editability Control

Use editability (instead of visibility) when:

Users need to see the information
But should not be able to change it
Data is for reference only
Separation of duties requires view-only access

Configuring Field Editability

Accessing Field Controls

Open Define Security Features
Select a security feature
In the Field Access part (embedded below the feature list), add a new line

Adding Fields with Editability Control

Use the assist edit (...) to select a table, field, and page
Set the Editable column to Readonly
Optionally keep the Visible column blank or set to Show

Editability Options

Setting	Field Behavior
Editable	Field is editable (if base allows)
Readonly	Field is read-only
(blank)	No editability override (inherits default)

Editability Control Examples

Example 1: Read-Only Financial Data

Allow viewing but not editing of financial fields:

Page	Field	Visible	Editable
G/L Entry	Amount	Yes	No
G/L Entry	Debit Amount	Yes	No
G/L Entry	Credit Amount	Yes	No

Example 2: Protected Posted Data

Prevent changes to posted document information:

Page	Field	Visible	Editable
Posted Sales Invoice	Posting Date	Yes	No
Posted Sales Invoice	Document Date	Yes	No
Posted Sales Invoice	Customer No.	Yes	No

Example 3: Approved Values

Protect values that require approval to change:

Page	Field	Visible	Editable
Customer Card	Credit Limit (LCY)	Yes	No
Vendor Card	Payment Terms Code	Yes	No

Combining Visibility and Editability

You can set both properties:

Visible	Editable	Result
(blank)	(blank)	Normal field (no ACS override)
Show	Readonly	View-only field
Hide	(any)	Hidden field

If a field is hidden, editability is irrelevant.

Editability Precedence

When multiple features control the same field:

User has Feature A: Field editable
User has Feature B: Field not editable
Result: Field is NOT EDITABLE

Read-only always wins - if any assigned feature makes the field read-only, it's read-only.

Dynamic Editability

Standard Business Central often has conditional editability:

Editable = NOT Rec.Posted;

ACS can work with these - see Handle Conflict Fields.

Combined Logic Example

Original: Editable = NOT Rec.Posted With ACS: Editable = NOT Rec.Posted AND ACSEditable

Field is editable only if BOTH:

Document is not posted
User has ACS permission to edit

Use Cases

Use Case 1: Separation of Duties

Sales team can see pricing but only pricing team can change:

User Role	Visibility	Editability
Sales	Yes	No
Pricing Team	Yes	Yes

Use Case 2: Approval-Based Editing

Some fields should only be changed through approval workflow:

Make field read-only for normal users
Field changes go through compliance approval
Approvers or automated process can update

Use Case 3: Reference Data Protection

Prevent accidental changes to setup data:

Data Type	Visible	Editable
Chart of Accounts	Yes	No (for most users)
Dimension Values	Yes	No (for most users)
Posting Groups	Yes	No (for most users)

Testing Editability Controls

Test Steps

Assign the feature to a test user
Log in as the test user
Navigate to the controlled page
Try to click/type in the field
Verify field cannot be modified

Expected Behavior

Field shows current value
Field appears grayed or disabled
Clicking field does nothing
Typing does not change value
Tab key skips the field

Test Checklist

Field displays correctly
Field shows current value
Cannot click into field
Cannot type in field
No error messages
Page functions normally otherwise

User Experience

Visual Indicators

Read-only fields typically show:

Grayed out appearance
Different background color
No cursor on hover
"Read-only" appearance

User Expectations

Users will understand:

They can view the data
They cannot modify it
This is a permission restriction
They need different access to edit

Training Points

Explain which fields are restricted
Clarify the reason (compliance, role-based, etc.)
Direct users to proper channels for changes

Common Scenarios

Scenario: Junior Employee Access

New employees get read-only access first:

Create "JUNIOR-READ-ONLY" feature
Add critical fields as editable = No
Assign to new employees
Remove assignment as they are trained

Scenario: Auditor Access

Auditors need to see everything but change nothing:

Create "AUDITOR-READ-ONLY" feature
Add all sensitive fields as editable = No
Assign to auditor accounts
Auditors can review without risk

Scenario: Historical Data Protection

Protect historical records from modification:

Create "HISTORY-PROTECTION" feature
Target fields on historical pages
Make editable = No
Assign broadly

Best Practices

Clear Purpose

Each feature should have a clear purpose:

"READ-ONLY-FINANCE" - financial data protection
"PROTECT-POSTED-DATA" - posted document protection
"VIEW-ONLY-SETUP" - setup data protection

Appropriate Scope

Match editability restrictions to job requirements:

Don't over-restrict (frustrates users)
Don't under-restrict (security risk)
Review and adjust as needed

Documentation

Record:

Which fields are read-only
Which pages are affected
Who is affected
Rationale for the restriction

Regular Review

Review restrictions periodically
Update as roles evolve
Remove unnecessary restrictions

Troubleshooting

Field Still Editable

If a field is still editable when it shouldn't be:

Verify feature is assigned to user
Check editability setting in feature
Confirm extension was regenerated
Check Effective Security for conflicts

Field Shows Error

If editing shows an error instead of being disabled:

This may be a validation error, not ACS
Check field's base permissions
Review conflict field handling