Advanced Cloud Security (+ Compliance)

Security Setup

Advanced Cloud Security extends standard Business Central security with UI-based security:

  • Page security: make an entire page read-only (or otherwise restricted).

  • Field security: make specific fields read-only, disabled, or hidden everywhere they appear.

  • Page control security: hide/disable controls that aren’t “real fields” (calculated tiles, cues, etc.).

  • Action security: disable menu/ribbon actions (you can disable actions; hiding actions is not supported).

  • Data-level filtering: apply security filters that remove records from pages and report request pages.

Key concept: you define “Security Features” (bundles of restrictions), and the app generates and installs a companion extension that contains the bindings required to enforce those restrictions in the places you selected.

Prerequisites and environment notes

  • Install Advanced Cloud Security from AppSource.

  • In a Sandbox, the app can be used to try things out without additional licensing steps.

  • You need permissions to:

    • Maintain app setup

    • Create/install extensions (SUPER and App. Management)

    • Assign security features to users/groups/permission sets

 

Initial setup and Symbols refresh

App setup

Open the app setup page and ensure:

  • App Name is set (an auto-generated name is provided; you may change it).

  • A free object number range is selected. You can change that if you have specific requirement for object number usage.

Refresh Symbols (required)

Symbols are the app’s “catalog” of what exists in your environment: tables, fields, pages, reports, actions, controls, etc.

Refresh symbols when:

  • A field/table/page you want to secure does not appear in lookups

  • You installed a new app/extension

  • You added or modified objects (new fields/pages)

How

  1. Go to Setup page (under Action) and make sure you have selected the correct platform. Select SaaS if you’re running Business Central in the cloud.

  2. Go to the app’s Symbols section.

  3. Choose Refresh Symbols.

  4. You have to authenticate 

  5. Return to your security feature definition and retry the lookup.

Defining Security Features (the core workflow)

A Security Feature is a bundle of related restrictions (group them by business scenario, not by technical object).

Typical examples:

  • “Sales Orders – Read Only”

  • “Customer – Hide Balances”

  • “G/L – Hide Net Change”

  • “Domestic Customers Only”

Create a new Security Feature

  1. Go to Define Security Features.

  2. Create New.

  3. Give the feature a meaningful name (example: Sales Orders).

Each feature can contain up to four types of rules:

  1. Fields

  2. Page Controls

  3. Actions

  4. Security Filters (data filters)

Page security (example: Sales Order read-only)

Scenario: Users can work with Quotes, but should not edit Sales Orders (even though they use similar tables).

Steps

  1. In your feature (e.g., Sales Orders), add a Page rule.

  2. Select the Sales Order page (example in video: Page 42).

  3. Set permission to Read Only.

Pages with embedded subpages (Header/Lines)

Some pages have embedded parts (e.g., Sales Order header + Sales Order Subform lines).

  • You may also select the subform page (video example: Page 146) to ensure line parts behave as expected.

  • In many cases, securing the main page is sufficient—but embedded pages can matter depending on layout and behavior.

Field-level security (global field restrictions)

Field rules apply everywhere the field appears, regardless of page.

Example scenario on the Customer table:

  • Address should be disabled

  • City should be read-only

Steps

  1. Create/open a feature (example: Customer).

  2. Add a Field rule.

  3. Select the Customer table.

  4. Select the target field:

    • Address → set to Disabled

    • City → set to Read Only

Note: If you can’t find tables/fields in lookups, you likely need to Refresh Symbols.

Page control security (for non-field UI elements)

Not everything on a page is a true database field. Some items are controls (cues/tiles/calculations).

In the video’s Customer Card example:

  • “Balance Due” controls were secured; one showed field number 0, indicating it’s a control rather than a direct table field.

Steps

  1. In your feature, add a Page Control rule.

  2. Select the page (e.g., Customer Card).

  3. Choose the control(s) you want to restrict.

  4. Set to Hidden to remove it from the UI.

Tip: If both a calculated control and a “real field” version exist, you may want to secure both, as shown in the video.

Action security (disable menu actions)

Actions are the functions in the ribbon/menu (e.g., Statistics).

Steps

  1. In your feature, add an Action rule.

  2. Select the page (e.g., Customer Card, Customer List).

  3. Select the action (actions may have odd internal names/IDs).

  4. Set to Disabled.

Important: Actions can be disabled, not hidden.

Data-level security filters (restrict which records are visible)

Security filters remove records from:

  • Pages (lists/cards)

  • Report request pages and report output that depend on UI-level filtering

Example in the video:

  • Only customers with Customer Posting Group = DOMESTIC should be visible.

Steps

  1. In your feature, add a Security Filter rule.

  2. Select the table (e.g., Customer).

  3. Select the field (e.g., Customer Posting Group).

  4. Choose one approach:

    • Static value: set filter to DOMESTIC (or your code)

    • User filter: choose “Get user filter for Customer Posting Group” (so the allowed value varies per user)

Understanding “User filters”

User filters let you maintain a matrix of:

  • user → allowed value(s) for a particular filter dimension

This is useful when you want one shared feature (e.g., “Restricted Customers”) but different users see different subsets.

Conflict fields (when another app controls the same UI element)

After selecting fields/controls, the app may show Conflict Fields. This means:

  • Another app (Microsoft or a third-party extension) already controls visibility/editability for that same UI element.

By default, Advanced Cloud Security “stays out” to avoid breaking existing behavior.

What to do when you must secure a conflict field

You can explicitly take control and define the default state when no security applies:

  • Use Visible (default visible unless security hides it)

  • Use Hidden (default hidden unless security allows it)

Example from video:

  • G/L “Net Change” visibility is also influenced by Microsoft settings (e.g., show net change vs debit/credit).

  • If you set “Use Visible/Hidden” here, your choice can override Microsoft’s behavior for that control.

Best practice: Only take over conflict fields when you understand what you’re overriding and why.

Create (generate) the security extension

After defining or changing Security Features, you must Create the Extension.

What happens

  • The app generates source code for the selected bindings.

  • It compiles them into an .app file.

  • The app is downloaded and also submitted for installation through Microsoft’s deployment service.

  • When deployment completes, the generated extension is installed.

When you must re-run Create Extension

Any time you:

  • Add/remove security features

  • Add new secured fields/pages/actions/controls/filters

  • Adjust conflict-field handling

Deployment approach (Sandbox → Production)

Common recommended flow:

  1. Configure and test in Sandbox

  2. Export/move your security feature configuration (e.g., via configuration package if you use that approach)

  3. Install the generated .app file in Production using Extension Management

Alternative:

  • Do everything directly in Production (works, but testing first is safer).

Scope across companies

Security Features and the generated extension operate at the environment/database level, meaning:

  • What you define applies across all companies in that environment.

If different companies require different rules, you must define all required variations and assign them appropriately.

Assign Security Features to users (and other assignment options)

Once the extension is installed, you can assign features.

14.1 Assign to a user

  1. Go to Assign Security to Users.

  2. Select the user (example: “Erik”).

  3. Add the desired features (e.g., Customer, GL, Sales Orders).

14.2 Assign to Security Groups

If you manage access via Business Central Security Groups, you can assign features to groups.

You set up the Security Groups in Microsoft Entra. If you have many groups, you might want to enable the Security Group Cache because updating security groups behind the scenes can take a few seconds. Go to Setup, activate the Security Group Cache and use the function to add a Job Queue Entry for periodic updating of the cache.

Assign to Permission Sets

You can “piggyback” security features onto permission sets:

  • If someone gets permission set X, they automatically get feature Y.

You can also combine user + group + permission set assignments.

Configure per-user security filter values

If you used User filters in a feature (instead of static values), set the user’s allowed values:

  1. Open Security Filters (user filter matrix).

  2. Find the user.

  3. Locate the filter dimension (e.g., Customer Posting Group).

  4. Set the allowed filter (example shown: DOMESTIC|'' meaning Domestic or blank).

Verify and audit: “See Effective Security”

To understand what a specific user actually gets:

  1. Open See Effective Security.

  2. Select the user.

  3. Review:

    • Field rules (disabled/read-only/hidden)

    • Page rules (read-only)

    • Action rules (disabled)

    • Active security filters

This is your primary troubleshooting and validation page.

Test the result (what users will experience)

Examples demonstrated in the video:

  • Customer List: records filtered out (e.g., foreign posting group customers disappear)

  • Customer Card:

    • Balance controls hidden (not visible)

    • Address disabled (greyed out)

    • City read-only

    • Statistics action disabled (greyed out)

  • Sales Order: entire page read-only; user cannot switch to edit mode

  • Reports:

    • Security filters affect report request page record selection and UI-facing report results

18. Important limitation: “Skin-deep” filtering

Security filters are applied to anything that touches the UI:

  • pages

  • report request pages and UI-driven datasets

They are not automatically applied to internal processing inside codeunits/background logic that does not rely on UI filtering.

Practical implication:

  • Security filters are excellent for UI-level data restriction and reducing accidental exposure.

  • For strict back-end enforcement, you may still need additional architectural controls (depending on your use case).

Troubleshooting checklist

“I can’t find the table/field/page/action in lookups”

  • Refresh Symbols.

“I updated features but nothing changed”

  • Re-run Create Extension after any definition change.

“A field says it’s a conflict field”

  • Decide whether to leave it alone (recommended) or take control using Use Visible/Use Hidden.

“The user can still click a button I don’t want them to”

  • Disable the relevant Action explicitly (page read-only doesn’t automatically disable every action).

“Works in one page but not in embedded lines”

  • Also secure the subpage/subform if needed.