Advanced Cloud Security Documentation
Index

Build Phase Overview

The Build phase is the first of three phases in Advanced Cloud Security. During this phase, you define what security rules you want to implement and generate the extension that enforces them.

What Happens in the Build Phase

The Build phase involves:

  1. Defining Security Features - Creating named collections of security settings
  2. Handling Conflict Fields - Resolving fields that already have security expressions
  3. Selecting Compliance Tables - Choosing tables for compliance tracking (optional)
  4. Creating the Extension - Generating the AL code that implements your rules

Scope of the Build Phase

The Build phase operates at the tenant level, affecting all companies:

Aspect Scope
Security Features Global (all companies)
Field Definitions Global (all companies)
Conflict Field Resolution Global (all companies)
Extension Generation Global (all companies)

This means you define security features once, and they're available to assign in any company.

Build Phase Interface

When you open the ACS main page, the Build phase appears in the first column:

  • Define Security Features - Opens the security feature configuration
  • Handle Conflict Fields - Opens the conflict field resolution page
  • Compliance Tables - Opens table selection for compliance (requires license)
  • Create Extension - Generates and compiles the extension

Understanding Security Features

A Security Feature is the core concept in ACS. It represents a named set of security rules that can be assigned to users.

Security Feature Components

Component Purpose
ID (Code) Unique identifier for the feature
Name Descriptive name shown to administrators
Description Detailed explanation of what the feature does
Field Controls Controls visibility and editability of fields
Action Controls Controls visibility of page actions
Data Access Defines record-level filters

Example Security Features

Feature ID Name Purpose
HIDE-COST Hide Cost Information Hides all cost-related fields
SALES-EUR European Sales Team Filters to European customers only
READ-ONLY-GL Read-Only General Ledger Makes GL fields non-editable
NO-POST Disable Posting Hides posting actions

Base Company Concept

ACS recommends designating a "Base Company" for administration:

  • Define security features in the base company
  • Changes are automatically available everywhere
  • Provides a consistent administration location
  • Set in ACS Setup

Build Phase Workflow

Step 1: Plan Your Security Model

Before configuring ACS, plan your security requirements:

  1. Identify sensitive data that needs protection
  2. Determine who should see what
  3. Define logical groupings (security features)
  4. Document your requirements

Step 2: Create Security Features

  1. Open Define Security Features
  2. Create a new feature for each security grouping
  3. Give it a meaningful ID and name
  4. Add description explaining its purpose

Step 3: Add Security Rules

For each security feature, add:

  • Field Controls - Which fields to hide or make read-only
  • Action Controls - Which actions to hide
  • Data Access - Which filter rules to apply

Step 4: Handle Conflict Fields

If any fields you've selected already have Visible/Editable/Enabled expressions:

  1. Open Handle Conflict Fields
  2. Review each conflict
  3. Choose how ACS should handle it
  4. Link conflicts to security features if needed

Step 5: Select Compliance Tables (Optional)

If using the Compliance module:

  1. Open Compliance Tables
  2. Select tables containing fields to track
  3. Configure list and card page associations

Step 6: Create Extension

This is the critical final step:

  1. Click Create Extension
  2. ACS generates AL code for your security rules
  3. The extension is compiled
  4. Install the extension in your environment

Step 7: Verify

After creating the extension:

  1. Refresh your browser
  2. Verify pages show correctly
  3. Test that security features are available to assign

When to Regenerate the Extension

You must regenerate the extension whenever you:

Change Regenerate Required
Add a new security feature Yes
Add fields to a feature Yes
Remove fields from a feature Yes
Delete a security feature Yes
Add compliance tables Yes
Change conflict field handling Yes
Change feature assignments No
Change user filter values No

Best Practices

Naming Conventions

  • Use clear, descriptive feature IDs
  • Include department or function in the name
  • Be consistent with your naming pattern

Feature Granularity

  • Create focused, single-purpose features
  • Combine multiple features for complex requirements
  • Avoid overly broad features that are hard to manage

Documentation

  • Use the description field thoroughly
  • Document which users should have each feature
  • Keep a change log of modifications