Security Roles, Duties & XDS Policies

How does F&O security work?

Simple explanation

Think of a company building with key cards.

Your role (employee, manager, executive) determines which floors you can access. Each floor has duties — things you’re responsible for (like “process payroll” or “approve invoices”). Each duty requires specific privileges — the actual actions you can perform (like “view employee records” or “post journal entries”). And each privilege maps to a specific door (menu item, button, or form) you can open.

F&O stacks these layers: Role → Duty → Privilege → Permission → Securable Object. You never give a user direct access to a form — you assign them a role, and the role’s duties and privileges determine what they can see and do.

The security hierarchy

┌─────────────────────────────────────────────────────────┐
│  USER (e.g. Elena Vasquez)                              │
│  └── ROLE: Production Manager                           │
│       ├── DUTY: Maintain production orders               │
│       │    ├── PRIVILEGE: Create production order         │
│       │    │    └── PERMISSION: ProdTable (Create)       │
│       │    │    └── PERMISSION: ProdTableListPage (Read) │
│       │    └── PRIVILEGE: View production schedule        │
│       │         └── PERMISSION: ProdSchedule (Read)      │
│       └── DUTY: Inquire into production status           │
│            └── PRIVILEGE: View production status          │
│                 └── PERMISSION: ProdStatus form (Read)   │
└─────────────────────────────────────────────────────────┘

Each layer explained

Five layers — from broadest (role) to most granular (securable object)
Layer	What it represents	AOT element	Example
Security Role	A job function assigned to users	SecurityRole	ProductionManager, AccountsPayableClerk
Duty	A business responsibility (group of privileges)	SecurityDuty	MaintainProductionOrders, InquireVendorInvoices
Privilege	Access to specific entry points at a given level	SecurityPrivilege	ProdTableCreate (Create access to ProdTable menu)
Permission	Exact access level on a securable object	Part of privilege definition	Read, Update, Create, Delete, or Invoke
Securable Object	The actual UI or service entry point	Menu item, service op, table	ProdTableListPage (menu item display)

Exam tip: Duties are the key design unit

When the exam asks about security design, duties are the most important layer:

Roles are assigned to users but are just containers for duties
Privileges are too granular for business discussion
Duties represent business responsibilities that auditors understand

Best practice: design duties first (based on business processes), then compose roles from duties. While you CAN assign privileges directly to roles, best practice is to go through duties for auditability and separation of duties (SoD) compliance.

Creating custom security elements

Custom roles

Step	Detail
1	In VS, right-click project → Add → New Item → Security Role
2	Name it descriptively: `PFProductionSupervisor`
3	Add duties (not individual privileges) to the role
4	Set the role’s context — which legal entities it applies to (if constrained)
5	Deploy and assign to users in System Administration → Users

Custom duties

Step	Detail
1	Add → New Item → Security Duty
2	Name: `PFMaintainQualityOrders`
3	Add privileges to the duty
4	Set the duty’s identifier (used for SoD conflict detection)

Custom privileges

Step	Detail
1	Add → New Item → Security Privilege
2	Name: `PFQualityOrderCreate`
3	Add entry point permissions: select menu items, set access level
4	Optionally add table permissions for direct data access

Entry point permissions

Entry points are the doors into F&O — each privilege specifies which doors it opens and at what level:

Entry point type	Example	Access levels
Menu item display	Forms and list pages	Read, Update, Create, Delete
Menu item output	Reports (SSRS)	Read (view/run the report)
Menu item action	Batch jobs, processes	Read (trigger the action)
Service operation	Web services, OData	Invoke

Scenario: Elena designs PacificForge security

Elena works with compliance officer Kenji to design the security model for PacificForge’s production module:

Role	Duties	Key privileges
PF Production Supervisor	Maintain production orders, View production KPIs, Approve quality orders	Create/update prod orders, view dashboards, approve quality
PF Production Operator	Record production output, View work instructions	Update route transactions, read-only on BOM
PF Quality Inspector	Maintain quality orders, Record test results	Create quality orders, update test measurements
PF Production Viewer	Inquire into production status	Read-only on all production forms

“Notice how the Operator can record output but can’t create or delete production orders,” Elena tells Sophie. “That’s least privilege — they get exactly what their job requires, nothing more.”

Extensible Data Security (XDS) — row-level security

The role/duty/privilege model controls which forms and actions a user can access. But what about which records they can see? That’s where XDS comes in.

What XDS does

XDS applies automatic WHERE clauses to queries, filtering data based on the user’s context. A regional manager sees only their region’s data — even though they have access to the same forms as other managers.

Without XDS:    SELECT * FROM SalesTable
                → Returns ALL sales orders (all regions)

With XDS:       SELECT * FROM SalesTable
                WHERE SalesTable.Region = 'Pacific'
                → Returns only Pacific region orders
                (filter injected automatically by XDS)

XDS policy components

Component	Purpose	Example
Policy	The top-level container	`PFRegionalDataPolicy`
Constrained table	The table being filtered	`SalesTable`, `CustTable`
Context	What determines the filter value	Current user’s role, current company, custom context
Policy query	The filter logic (WHERE clause)	`SalesTable.Region = getCurrentUserRegion()`
Context type	`RoleBased` (most common) or `Application` context	Role-based filters by role membership; application by runtime value

Building an XDS policy

// XDS Policy definition in AOT
// Policy: PFRegionalSalesPolicy
// Constrained table: SalesTable
// Context type: RoleBased
// Primary table: SalesTable

// The policy query joins SalesTable to a mapping table
// that links users to regions. When the policy is active,
// every query against SalesTable automatically includes:
// EXISTS (SELECT 1 FROM UserRegionMapping
//         WHERE UserRegionMapping.Region = SalesTable.SalesRegion
//         AND UserRegionMapping.UserId = currentUserId())

Scenario: Elena implements regional data security

PacificForge has three regional offices (Pacific, Americas, Europe). Each regional sales manager should only see their region’s customers and orders.

Elena’s XDS implementation:

Creates a UserRegionMapping table linking user IDs to regions
Creates an XDS policy PFRegionalDataPolicy with:
- Constrained tables: SalesTable, CustTable, SalesLine
- Context: RoleBased (applies when user has the Regional Sales Manager role)
- Query: EXISTS join to UserRegionMapping where Region matches
Assigns the policy to the PF Regional Sales Manager role

Result: when a Pacific manager opens the Sales Orders list, they automatically see only Pacific region orders. The WHERE clause is injected invisibly — no code changes needed on any form.

“The beauty is that every form, every report, every export that touches SalesTable is automatically filtered,” Elena tells DBA Harpreet. “We don’t have to modify each one individually.”

Exam tip: XDS vs form-level filtering

The exam may present scenarios where you need to choose between XDS and form-level filtering:

XDS — automatic, applies everywhere (forms, reports, exports, services), enforced at the database query level. Use for security requirements.
Form-level filtering — manual, applies only to that form, can be bypassed. Use for convenience/UX, not security.

If the requirement says “users must NOT be able to see other regions’ data” → XDS (security). If it says “default the form to the user’s region” → form filter (convenience).

Security diagnostics

Troubleshooting access issues

Tool	Purpose	Location
Security diagnostics	Traces why a user can or can’t access something	System Administration → Security → Security diagnostics
View permissions	Shows all effective permissions for a user	User details → View permissions
Role assignments	Lists all roles assigned to a user	System Administration → Users → select user → Assign roles
Security configuration	Visualises the role → duty → privilege tree	System Administration → Security → Security configuration
Segregation of duties	Detects conflicting duties assigned to the same user	System Administration → Security → Segregation of duties

Scenario: Debugging a missing menu item

Sophie reports that a production operator can’t see the “Record Output” menu item. Elena’s debugging steps:

Check role assignment — is the user assigned the PF Production Operator role? ✅ Yes
Check duty — does the role include the “Record production output” duty? ✅ Yes
Check privilege — does the duty include the privilege for the menu item? ❌ Missing!
Fix — add the ProdRouteTransCreate privilege to the duty
Verify — re-check using Security Diagnostics → user can now see the menu item

“Always start from the user and work down the chain,” Elena advises. “Role → Duty → Privilege → Entry Point. The break is almost always a missing privilege.”

Segregation of duties (SoD)

SoD rules prevent users from having conflicting responsibilities — like “create vendor” AND “approve vendor payments” (fraud risk).

Concept	Detail
SoD rule	Defines two duties that should never be assigned to the same user
SoD conflicts	System reports violations when roles create conflicts
Resolution	Split duties across different roles, or document an exception
Audit trail	SoD violations are logged for compliance auditing

Question

What are the five layers of the F&O security hierarchy, from broadest to most granular?