Access Policies (HCM Administration)

This page documents the shipped Access Policies screen (hcm-admin-console). It has two parts: a policy manager for fine-grained access rules, and the tenant-wide session and security settings. Not for plugin developers.

How policies work (read this first)

A policy answers one question: may this person do this to this data? It has four parts you fill in:

Part	You choose	Example
Who (subjects)	roles, users, departments and so on	role HR_MANAGER
What data (resource)	a resource code	HCM.EMPLOYEE.PROFILE
What they may do (actions)	View, Edit, Export, ...	View
Effect	Allow or Deny	Allow

Rules the system follows every time:

1. A Deny always beats an Allow.
2. Among policies of the same effect, the one with the higher priority number wins.
3. If a resource is named by any active policy, everyone that no policy allows is denied for that resource. If no active policy names it, nothing changes and the module works as it always did.
4. Policies never restore access a module already denies; they can only narrow it further or hide and mask fields.
5. Changes take effect within about 15 seconds of publishing.

Where policies are enforced today: only the Employee module (HCM.EMPLOYEE.PROFILE), on the employee directory list and when a single employee record is opened. See "Known limits" below before relying on another resource.

Set up your first policy, step by step

This example lets HR Managers view employee records, hides date of birth, and masks phone numbers. Everyone else is then denied for employee records, so do the steps in order.

Step 1. Check who has the role

Policies match on the roles users are assigned. Open HCM Users, open the user, go to Access & Roles, and confirm the person has the role (for example HR_MANAGER). Role codes you can use include HR_ADMINISTRATOR, HR_MANAGER, HR_EXECUTIVE, EMPLOYEE and AUDITOR.

Step 2. Create the policy

Open Access Policies and press New Policy. Work through the tabs:

1. Basic Info — Policy Code HR_MANAGER_VIEW_EMPLOYEES (letters, digits, _, ., - only), a Policy Name, Policy Type RECORD_ACCESS, Effect ALLOW, Priority 50.
2. Subjects — Subject Type ROLE, Subject Code HR_MANAGER, press Add. Add one line for each role that should keep access (for example also HR_ADMINISTRATOR and AUDITOR, otherwise they lose it).
3. Resources — pick HCM.EMPLOYEE.PROFILE and press Add.
4. Access Scope — GLOBAL (needed for the directory list; see "Known limits").
5. Conditions — leave empty.
6. Actions — VIEW.
7. Restrictions — to hide date of birth: Restriction HIDE, Field dateOfBirth, Add. To mask phone numbers: Restriction MASK, Field phone, Masking mode PHONE_MASK, Add.
8. Schedule — leave empty for "always", or set dates, days, a time window or network zones.
9. Review & Publish — read the summary. A red warning appears when a policy allows everything globally. Press Save Draft to keep working later, or Publish to make it live.

Field names in Restrictions are the names in the employee record, for example phone, email, dateOfBirth, nationality, maritalStatus, bloodGroup, workMode. A name that does not exist is simply ignored.

Step 3. Publish, and read the result

Publish checks the policy. If something is wrong the message names it (for example an unknown action, or a time window with only one end). If another active policy with the opposite effect and equal or higher priority covers the same resource and people, publishing is blocked and the message names that policy; change one of their priorities, subjects or resources, or deactivate the other one.

Step 4. Test it before you rely on it

Click the policy in the list and press Test. Fill in a sample request: Resource HCM.EMPLOYEE.PROFILE, Action VIEW, and User's role codeHR_MANAGER, then Evaluate. You should see Decision: ALLOW, which policy matched, and the field restrictions. Try again with a role that is not in your list (for example EMPLOYEE): the answer should be DENY.

Test evaluates active policies, so publish first. A test changes nothing.

Step 5. Check it for real

Sign in as a user with the role and open the employee directory. Phone numbers are masked, and date of birth is missing from a single employee record. Sign in as a user without the role: the directory says access is denied by an access policy.

Step 6. Change or undo it

• Change a live policy: open it and press Create Version. Edit the new draft, then Publish. The old version stops applying when the new one is published.
• Switch it off: press Deactivate (you can Activate it again). Once no active policy names the resource, employee access returns to how it was before, within about 15 seconds.
• Retire it: Archive. Only drafts can be deleted.
• Locked out by mistake? Policies are managed on this page, which is not itself restricted by them. Open the policy and press Deactivate.

More examples

Goal	Policy
Only the person's own record	Effect Allow, Subject Type DYNAMIC_SUBJECT code CURRENT_USER, Scope SELF, Action VIEW (applies when a single record is opened; the directory list needs a Global policy)
Block one user	Effect Deny, Priority higher than your Allow, Subject Type USER, code = their login name
Only HR administrators can see salaries	Allow VIEW for role HR_ADMINISTRATOR on resource HCM.EMPLOYEE.COMPENSATION; nobody else is allowed, so they are denied (the person still needs the existing Employee.ViewSalary permission)
Auditors can view but not export	Allow VIEW for role AUDITOR, plus Restriction NO_EXPORT
Office hours only	Any Allow policy, Schedule: days Mon to Fri, Start 09:00, End 18:00, Timezone Asia/Kolkata
Temporary access	Any Allow policy, Schedule: Effective From and Effective To dates; it stops applying by itself after the end date
Everyone can view, but hide contact details	Allow VIEW with no subjects (means everyone), Restrictions MASK on phone and email

What each part of the editor offers

• Subjects — roles, users, groups, positions, designations, job grades, departments, business units, locations, employee categories, employment types, managers, or dynamic subjects such as "the requester's own department". No subjects means everyone. Today the system supplies the requester's roles, user name and org units on its own; other subject types only match when a caller supplies them (see "Known limits").
• Access Scope — Global, Organization, Legal Entity, Business Unit, Division, Department, Team, Location, Branch, Cost Center, Reporting Tree, Self, Direct Reports or Custom Filter.
• Conditions — field, operator and value rules combined with AND, OR or NOT; operators are =, !=, >, <, >=, <=, IN, NOT IN, CONTAINS, STARTS WITH, IS NULL, IS NOT NULL, BETWEEN.
• Actions — View, Create, Edit, Delete, Approve, Reject, Submit, Cancel, Export, Import, Download, Print, Share, Assign, Reassign, Delegate. Empty means every action.
• Restrictions — HIDE removes a field, MASK rewrites it (full, partial, last 4, first 4, email, phone, custom), READ_ONLY marks it read-only, and NO_EXPORT, NO_DOWNLOAD, NO_PRINT turn those actions into a deny even when the policy allows viewing.
• Schedule — effective dates, days of the week, a time window with a timezone, allowed network zones.

The policy list

The list shows every policy as a card with its status (Draft, Active, Inactive, Archived). Click a policy to open its details. Depending on its status you can Edit (drafts only), Publish, Activate, Deactivate, Create Version, Clone, Test, View History, Export JSON, Archive or Delete (drafts only). Published policies are never edited in place: create a new version. Import accepts pasted policy JSON and shows a validation preview (counts, errors, warnings) before creating a draft.

Tenant session and security settings

Below the policies, the same page holds the tenant-wide login controls:

• Session Policy — Idle Timeout (minutes), Absolute Timeout (hours), Concurrent Session Limit.
• Security Policy — CAPTCHA After Failed Attempts, Allowed Login Start and End Hour, IP allow list, IP deny list, allowed login countries (comma or line separated) and an Enforce Strict Sessions toggle.

These are enforced at sign-in. Be careful with the IP allow list: an address that excludes you can lock you out.

Known limits

• Only some screens apply policies today:

  • the employee directory list and a single employee's record (resource HCM.EMPLOYEE.PROFILE);

  • an employee's salary history and current salary (HCM.EMPLOYEE.COMPENSATION);

  • the payslip screens: your latest payslip, its plain-language explanation, and the payslip PDF download (HCM.PAYROLL.PAYSLIP). The PDF can only be allowed or denied (use the DOWNLOAD action); it cannot have individual figures hidden. When a payslip figure is hidden or masked, the explanation shows a short notice instead of the figures.

  • the compensation comparison screen (HCM.EMPLOYEE.COMPENSATION; when a figure is hidden, the totals are hidden too), the payroll dashboard summary and the country contribution rollup (HCM.PAYROLL.SUMMARY). These are organization-wide totals, so only Global-scope policies apply to them.

  • any screen built on an entity, by naming the entity as ENTITY.<ENTITY_NAME_IN_UPPER_CASE> (for example ENTITY.PAYROLL_RUN). This allows or denies whole-entity access (view, create, edit, delete) for every page that uses the entity. It cannot hide or mask individual fields, only Global-scope policies apply, and export is treated as viewing.

  Data-service based dashboards and other plugin screens that are not built on an entity, Leave, Attendance, Recruitment and the other modules do not call the policy engine yet, so a policy naming their resources changes nothing there except in the Test dialog.

• Publishing a policy for a resource switches that resource to "deny unless allowed". Once any active policy names HCM.EMPLOYEE.PROFILE, users no policy allows lose access to it. Publish an Allow policy for the people who need access before, or together with, any restriction. To undo, deactivate the policy; it takes effect within about 15 seconds.

• On the employee directory list only Global-scope policies apply; Self, Direct Reports and Department scopes are applied when a single employee record is opened.

• Network-zone restrictions cannot be evaluated at runtime yet (there is no trusted network-zone service), so a policy limited to a network zone denies everyone; use it only in the Test dialog for now.

• Validation checks the shape of a policy, not that a role, department or resource code actually exists.

• There is no resource tree, drag-and-drop designer or action matrix; the editor uses forms and lists.

• Sensitive-data classification and a per-decision audit trail are not built.

Related

• HCM Roles & Permissions
• HCM Users
• Approval Hierarchies