Advanced Cloud Security Documentation
Index

Field Security Overview

Field-level security is a core capability of Advanced Cloud Security. It allows you to control the visibility and editability of individual fields on pages, going beyond Business Central's standard permission model.

What is Field-Level Security?

Field-level security controls:

  • Visibility: Whether a user can see a field
  • Editability: Whether a user can modify a field's value

Unlike standard BC permissions (which control table access), field-level security operates at the page/UI level.

Why Field-Level Security Matters

Business Central's built-in security:

Capability Standard BC ACS Field Security
Table access ✓ N/A
Object access ✓ N/A
Field visibility ✗ ✓
Field editability ✗ ✓

ACS fills the gap for scenarios like:

  • Hide salary information from non-HR users
  • Make certain fields read-only for specific roles
  • Prevent accidental changes to critical data

How Field Security Works

At Design Time

  1. You define security features with field controls
  2. Specify which fields on which pages
  3. Set visibility and/or editability
  4. Generate the extension

At Runtime

User Opens Page
      ↓
ACS Evaluates User's Security Features
      ↓
For Each Controlled Field:
  - Check visibility setting
  - Check editability setting
      ↓
Apply Settings to Page
      ↓
User Sees Personalized Page

Field Control Options

Each field control has three independent settings. A blank value means ACS does not override the default behavior.

Visible

Setting Effect
(blank) No override - field uses default visibility
Show Field appears on page
Hide Field is completely hidden

Enable

Setting Effect
(blank) No override - field uses default enabled state
Enable Field is enabled
Disable Field is disabled (grayed out)

Editable

Setting Effect
(blank) No override - field uses default editability
Editable Field can be modified (if base permissions allow)
Readonly Field is read-only, value visible but not changeable

Common Combinations

Visible Editable User Experience
Hide (blank) Field not visible at all
Show Readonly Can see but cannot modify
(blank) (blank) Normal - no ACS override

Security Feature Field Controls

Field controls are defined within security features:

Security Feature: HIDE-COST
├── Field: Item Card - "Unit Cost" (Visible: No)
├── Field: Item Card - "Last Direct Cost" (Visible: No)
├── Field: Item List - "Unit Cost" (Visible: No)
└── Field: Purchase Line - "Direct Unit Cost" (Visible: No)

Pages vs. Tables

Important Distinction

ACS field security works at the page level, not the table level:

Level What You Control Example
Page Specific page's display Customer Card page
Table Underlying data Customer table

The same field may appear on multiple pages. You must configure each page where you want to control the field.

Example: Customer Credit Limit

The "Credit Limit (LCY)" field might appear on:

  • Customer Card
  • Customer List
  • Mini Customer Card
  • Customer Statistics FactBox

To fully hide it, configure all these pages.

Inheriting Controls

When multiple features control the same field:

Feature A Feature B Result
Visible: Show Visible: Hide Hidden (Hide wins)
Editable: Editable Editable: Readonly Readonly (Readonly wins)
Visible: Hide Editable: Readonly Hidden (Hide wins)

Most restrictive setting wins.

Field Security Scenarios

Scenario 1: Hide Sensitive Information

Use case: Hide cost fields from non-purchasing staff

Implementation:

  1. Create feature "HIDE-COST"
  2. Add all cost-related fields
  3. Set Visible = Hide
  4. Assign to appropriate users/groups

Scenario 2: Read-Only Financial Data

Use case: Let users view but not modify financial data

Implementation:

  1. Create feature "READ-ONLY-FINANCE"
  2. Add financial fields
  3. Set Editable = Readonly (leave Visible blank or set to Show)
  4. Assign to appropriate users

Scenario 3: Tiered Access

Use case: Different access levels for same data

Implementation:

  • Feature "FULL-ACCESS" - no restrictions
  • Feature "VIEW-ONLY" - Editable = Readonly
  • Feature "NO-ACCESS" - Visible = Hide

Assign based on user role.

Configuration Process

Step 1: Identify Fields

  1. List sensitive fields that need protection
  2. Identify all pages where they appear
  3. Determine who should have restricted access

Step 2: Create Security Feature

  1. Open Define Security Features
  2. Create new feature
  3. Name it clearly (e.g., "HIDE-SALARY-INFO")

Step 3: Add Field Controls

  1. In the Field Access part (embedded on the Security Features page), add entries
  2. Select table, field, and page for each entry
  3. Set Visible, Enable, and/or Editable settings

Step 4: Generate Extension

  1. Click Create Extension
  2. Install the extension
  3. Refresh browser

Step 5: Assign Feature

  1. Assign to users, groups, or permission sets
  2. Verify with Effective Security
  3. Test with actual users

Best Practices

Comprehensive Coverage

  • Check all pages where a field appears
  • Don't forget list pages, card pages, factboxes
  • Consider report previews if applicable

Logical Grouping

  • Group related fields in one feature
  • Easier to manage and assign
  • Clear purpose for each feature

Documentation

  • Document why each field is controlled
  • List affected pages
  • Record who should have the feature

Testing

  • Test with affected users
  • Verify all pages show correctly
  • Check for unintended side effects

Limitations

What Field Security Cannot Do

Cannot Do Explanation
Hide from reports Reports access data directly
Hide from APIs API access bypasses page security
Prevent database access Works at UI level only
Override base permissions Can't show what user can't access

Security Considerations

Field-level security is UI security:

  • Protects against casual viewing
  • Good for role-based access control
  • Not a substitute for data-level security
  • Combine with proper permissions for defense in depth