Advanced Cloud Security Documentation
Index

Data Security Overview

Data-level security in Advanced Cloud Security allows you to filter which records users can see. Unlike field-level security (which controls individual fields), data security controls which rows of data appear.

What is Data-Level Security?

Data-level security applies filters to tables, restricting which records a user can see:

Security Type Controls Example
Field-level Which fields are visible Hide "Unit Cost" field
Data-level Which records are visible Show only European customers

Why Use Data Filters?

Common scenarios for data filtering:

  • Regional access: Sales reps see only their region's customers
  • Departmental isolation: Show only own department's data
  • Location-based access: Warehouse staff see their location only
  • Ownership filtering: Users see only records they own

How Data Filtering Works

At Design Time

  1. Define a security feature
  2. Add data access rules (filters)
  3. Specify table, field, and filter expression
  4. Generate the extension

At Runtime

User Opens List Page
        ↓
ACS Evaluates Data Access Rules
        ↓
Applies Filters to Table
        ↓
User Sees Only Matching Records

Filter Application

Automatic Filtering

Filters apply automatically:

  • User doesn't see filter criteria
  • Records simply don't appear
  • No "filtered" indicator
  • Clean user experience

Transparent Operation

From the user's perspective:

  • The filtered data appears to be all the data
  • No error messages
  • No "access denied"
  • Normal page operation

Data Access Rule Components

Each data access rule specifies:

Component Description Example
Table No. The table to filter 18 (Customer)
Field No. The field to filter on 7 (Country/Region Code)
Filter Expression The filter criteria `DE FR IT`

Filter Expression Types

Static Filters

Fixed values that apply to all users with the feature:

Country/Region Code = 'DE|FR|IT'

All users with this feature see only customers in Germany, France, or Italy.

Dynamic Filters

Values that resolve per user:

Salesperson Code = filter code UF_21 (Salespers./Purch. Code)

Each user sees customers assigned to their salesperson code. The value of UF_21 is configured per user in the User Security Filters page.

Multiple Filters

Same Feature, Multiple Tables

A feature can filter multiple tables:

Feature: EUROPE-SALES
├── Customer: Country/Region Code = 'DE|FR|IT|ES'
├── Sales Header: Sell-to Country = 'DE|FR|IT|ES'
└── Item Ledger Entry: Country/Region = 'DE|FR|IT|ES'

Multiple Filters on Same Table

Multiple filters on the same table combine with AND:

Feature: ACTIVE-HIGH-VALUE
├── Customer: Blocked = '' (active customers)
└── Customer: Credit Limit > 10000 (high value)

User sees customers who are both active AND high-value.

Data Security Scenarios

Scenario 1: Regional Sales Teams

Feature: SALES-NORTH
Filter: Customer."Sales Region" = 'NORTH'

Feature: SALES-SOUTH  
Filter: Customer."Sales Region" = 'SOUTH'

Assign appropriate feature to each sales team.

Scenario 2: Department Data

Feature: FINANCE-DEPT
Filter: G/L Entry."Global Dimension 1 Code" = 'FINANCE'

Finance users see only finance-related entries.

Scenario 3: User-Specific Records

Feature: OWN-DOCUMENTS
Filter: Sales Header."Assigned User ID" = filter code UF_50 (User ID Filter)

Users see only documents assigned to them.

Filter Behavior

View Operations

Filters apply to:

  • List pages
  • Lookups
  • FactBoxes
  • FlowFields (indirectly)

Modification Operations

When filters restrict data:

  • User can only modify visible records
  • Creating new records may be allowed
  • New records may or may not be visible after save

Combining with Field Security

Data security and field security work together:

Security Type Controls
Data filters Which customers you see
Field visibility Which fields on customer card
Field editability Which fields you can modify

Example:

Feature: SALES-TEAM
├── Data Filter: Customer."Country/Region Code" = filter code UF_22
├── Field Hidden: Customer."Credit Limit"
└── Field Read-Only: Customer."Payment Terms"

Limitations

What Data Filters Cannot Do

Limitation Explanation
Reports Reports may access unfiltered data
APIs API access bypasses filters
FlowFields Some FlowFields may show unfiltered counts
Lookups Lookup behavior may vary

Security Consideration

Data filtering is an additional security layer:

  • Not a replacement for table permissions
  • Use alongside proper permission sets
  • Consider for role-based data isolation
  • Audit access periodically

Best Practices

Use Indexed Fields

Filter on indexed fields for performance:

  • Primary key fields
  • Common filter fields
  • Fields in the table's keys

Document Filter Logic

Record:

  • What data is filtered
  • Filter criteria
  • Who is affected
  • Business justification

Test Thoroughly

  • Verify correct records appear
  • Check edge cases
  • Test lookups and related pages
  • Confirm filter doesn't break workflows

Consider Dependencies

When filtering parent tables:

  • Consider impact on child records
  • Test related list pages
  • Verify lookups still work