2.3 Security Filters, Change Log & Security Auditing

Security Filters, Change Log & Security Auditing

Enterprise implementations demand granular data segregation and comprehensive auditing. Dynamics 365 Business Central provides a defense-in-depth architecture consisting of record-level security filters, passive historical change logs, real-time field monitoring alerts, and cloud telemetry integration via Azure Application Insights.

---

Record-Level Security Filters: Architecture & Syntax

While standard permission sets control table-level access (e.g., whether a user can read TableData 18 Customer), data governance often requires row-level segregation. For example, an organization may require regional sales agents to access only customers located in their assigned territory, or prevent junior accountants from viewing confidential payroll general ledger accounts.

In Business Central, row-level security is enforced via Security Filters applied directly to TableData lines within User-Defined Permission Sets.

Configuring Security Filters

1. Open Tell Me (Alt+Q) and search for Permission Sets (Page 9802).
2. Select a User-Defined permission set and choose Permissions.
3. Locate the target TableData row (e.g., TableData 18 Customer or TableData 15 G/L Account).
4. Scroll to the Security Filter column and click the ellipsis (...) to open the Table Filter dialog.
5. Select the field to filter upon and specify the filter expression.

Filter Syntax & Practical Applications

Security filters use standard Business Central filter expressions:

• Number Ranges: 1000..1999 applied to No. on TableData 15 (G/L Account) restricts the user to view and post only balance sheet asset accounts.
• Multiple Discrete Values: NORTH|WEST applied to Territory Code on TableData 18 (Customer) limits user visibility to customers in the North or West territories.
• Exact Matches: ='DOMESTIC' applied to Customer Posting Group restricts visibility strictly to domestic accounts.
• Exclusions: <>PAYROLL applied to Global Dimension 1 Code prevents the user from viewing any transaction or account tagged with the Payroll department dimension.

Runtime Behavior & Transaction Rollbacks

Understanding how security filters interact with application execution is critical for functional consultants:

• List Page Filtering: When a user opens a list page (e.g., Customer List), Business Central automatically injects the security filter into the SQL query's WHERE clause. Rows outside the filter criteria are invisible. The user cannot clear this filter using the UI filter pane.
• Lookup Validation: If a user attempts to manually enter a customer number or G/L account outside their security filter, Business Central rejects the input as an invalid record.
• Posting Abort Hazard: If a user initiates an automated posting routine (e.g., posting a sales invoice) and the posting codeunit attempts to read, validate, or insert a record that violates the user's security filter (for example, reading a restricted rounding G/L account or tax account), the entire transaction terminates immediately with a runtime error and rolls back all database changes.

Architectural Limitations

• No FlowFields: Security filters cannot be applied to FlowFields or FlowFilters; they can only be defined on physical database fields.
• Indexing & Performance: Because security filters are injected into every SQL query executed on that table, applying filters to unindexed fields on large tables forces SQL Server to perform full table scans. Always apply security filters to indexed key fields.
• The SUPER Exception: If a user is assigned the built-in SUPER permission set without a company filter, Business Central bypasses all security filters completely.

---

The Change Log: Comprehensive Historical Auditing

Regulatory compliance standards (SOX, ISO 27001, GDPR) require organizations to maintain verifiable audit trails of changes made to master data and system configuration. Business Central fulfills this through the native Change Log mechanism.

Activating and Configuring Change Log

1. Open Tell Me -> Change Log Setup (Page 592).
2. Check the Change Log Activated toggle.
3. Choose Actions -> Setup -> Tables to open the Change Log Setup (Table) List.
4. For each table requiring auditing, configure the three operational events:
   • Log Insertion: [Blank], Some Fields, or All Fields.
   • Log Modification: [Blank], Some Fields, or All Fields.
   • Log Deletion: [Blank], Some Fields, or All Fields.
5. If Some Fields is selected for Modification, click into the table's field list and check the specific fields that warrant tracking.

Inspecting Change Log Entries

When an audited table or field is modified, Business Central writes an immutable record to Table 405 Change Log Entry. Users inspect these records via Tell Me -> Change Log Entries (Page 595).

Each Change Log Entry captures complete forensic metadata:

• Entry No.: Unique sequential integer.
• Date and Time: Exact UTC timestamp of the commit.
• User ID: The authentication identity who committed the change.
• Table No. & Table Caption: The database table affected (e.g., Table 23 Vendor).
• Field No. & Field Caption: The specific field altered (e.g., Field 8 Address).
• Type of Change: Insertion, Modification, or Deletion.
• Old Value: The field value prior to the edit.
• New Value: The newly committed field value.

Audit Immutability: Change Log Entries are strictly read-only within the Business Central application. Even users with the SUPER role cannot edit or delete individual change log records from the user interface.

Performance Hazards & Best Practices

A common point of failure in real-world implementations—and a central concept tested on the MB-800 exam—is the misconfiguration of Change Log on transactional ledger tables.

The Transaction Ledger Rule

Never enable the Change Log on high-volume transactional ledger tables! Tables such as Table 17 (G/L Entry), Table 21 (Cust. Ledger Entry), Table 25 (Vend. Ledger Entry), and Table 32 (Item Ledger Entry) are already immutable append-only ledgers by design. Every financial transaction posted in Business Central writes permanent records containing user stamps, dates, and document references.

Enabling Change Log on ledger tables creates severe operational disasters:

• Every posted invoice line generates dozens of redundant change log entries.
• High-volume batch posting encounters massive SQL lock contention on Table 405 (Change Log Entry), causing posting deadlocks and timeouts.
• Database storage expands exponentially, driving up cloud infrastructure costs.

Change Log Best Practices:

• Audit Setup Tables: Enable All Fields on core setup tables that dictate financial behavior (e.g., General Ledger Setup, Sales & Receivables Setup, Purchases & Payables Setup, Posting Groups).
• Audit Master Data Selectively: Use Some Fields on master entities (e.g., Customer, Vendor, Item, Bank Account) to track critical attributes such as Credit Limit, Payment Terms, or Posting Group assignments.
• Implement Retention Policies: Use the native Retention Policies framework (Tell Me -> Retention Policies) to automatically delete Change Log entries older than an organizationally approved retention window (e.g., 1 year or 3 years) using scheduled background job queues.

---

Monitored Fields: Real-Time Fraud Prevention

While the Change Log provides passive historical auditing, it requires someone to manually review log entries after the fact. In high-risk areas such as corporate treasury and vendor management, passive logging is insufficient to stop internal fraud.

A common fraud scheme involves a compromised user changing a legitimate vendor's bank routing details to a personal account, waiting for a payment batch to execute, and then switching the bank details back. To prevent this, Business Central provides Field Monitoring (Monitored Fields).

Configuring Monitored Fields

1. Navigate to Tell Me -> Monitored Fields Worksheet (Page 1362).
2. Add the sensitive table and field combinations. Standard audit fields include:
   • Table 23 Vendor -> Field 59 Our Account No.
   • Table 288 Vendor Bank Account -> Field 11 Bank Account No. / IBAN / SWIFT Code
   • Table 27 Item -> Field 18 Unit Cost
   • Table 98 General Ledger Setup -> Field 10 Allow Posting From
3. Navigate to Tell Me -> Field Monitoring Setup (Page 1360).
4. Specify the Notification Email (e.g., compliance@company.com) and the User ID of the compliance officer.
5. Enable the monitoring service.

Operational Alerting & Anti-Tamper Security

• Immediate Email Dispatch: The instant a user commits a change to a monitored field, Business Central logs the modification to Monitored Field Log Entries and dispatches an immediate email alert to the designated notification address detailing who made the change, the old value, and the new value.
• Anti-Tampering Self-Defense: To ensure a rogue administrator cannot silently disable field monitoring before executing a fraudulent edit, modifying or disabling the Field Monitoring Setup itself requires administrative re-authentication, logs an audit entry, and sends an immediate high-priority warning email to the security team.

---

Enterprise Security Telemetry & Application Insights

For enterprise threat detection and comprehensive IT governance, Business Central environments can be connected directly to Azure Application Insights.

Configured within the Business Central Admin Center, Application Insights streams live platform telemetry to Azure Monitor without generating database overhead. Key security and operational events captured include:

• Authorization Failures: Tracks error code RT0004 (permission denied) to identify users attempting to access restricted tables or unauthorized pages.
• Privilege Escalations: Records when a user is granted the SUPER permission set or added to an administrative security group.
• Data Export Events: Logs when users execute Open in Excel, Edit in Excel, or bulk data export routines, enabling compliance teams to detect potential data exfiltration of customer or financial lists.
• Session Anomalies: Analyzes login geographic locations, authentication failures, and concurrent user sessions.

Security analysts use Kusto Query Language (KQL) in Azure Monitor to create real-time alert rules that notify IT teams if anomalous export volumes or repeated authorization rejections occur.

---

Governance & Auditing Comparison Matrix

---

Common Pitfalls & Exam Gotchas

• Enabling Change Log on G/L Entry: A classic MB-800 question asks why batch posting became painfully slow after activating Change Log. The answer is almost always that Change Log was turned on for transactional ledger tables (Table 17, 21, 25, or 32).
• FlowField Security Filter Myth: Attempting to place a security filter on a FlowField (such as Customer Balance (LCY)) is impossible and will throw an error. Security filters can only filter on stored database fields.
• Assuming Change Log Blocks Modifications: Change Log is purely passive and retrospective. It records that a change occurred; it does not prevent the user from making the change. To prevent unauthorized modifications, administrators must use Permissions or Security Filters.
• Bypassing Security Filters with Global SUPER: When testing security filters, functional consultants often log in using their own administrative account and observe that the filter does not work. This occurs because the SUPER role assigned without a company filter automatically bypasses all record-level security filters.