Skip to main content
Eptura Knowledge Center

Introducing Archibus Application Security

Application Security

Overview


The Archibus applications use security groups to determine the database data that a user can access and edit, and the Navigator entries that appear on their system.

Archibus security operates on three layers:

  • Authentication – Verifying user identity (local credentials, LDAP, SAML/SSO).
  • Hierarchical Security – Controls which tasks, views, and fields a user can access via roles and groups.
  • Virtual Private Archibus (VPA) – Restricts which rows of data a user can see or edit based on site, building, legal ID, department, etc.

Best Practices


Below are a few best practices that we recommend.

  • Groups → Roles → Users — Always assign groups to roles, not directly to users.
  • Hierarchical Groups Use these to reduce the number of groups to maintain. Design group codes so lower levels are prefixes of higher ones.
  • Substring vs. prefix Wildcards (%) are powerful but can be overly broad. Use prefix groups for precision.
  • Prefer VPA Groups over role-level restrictions for multi-site deployments -— Plan the migration since enabling VPA Groups disables legacy restrictions.
  • Start with least privilege — Expand based on validated need.
  • Audit quarterly — Review group assignments and VPA mappings for drift.
  • Test per role —  Have a representative user from each group validate access before go-live.

Setup Sequence


Create in this order: Security Groups → Roles → Users.

Then assign groups and processes to roles.

Step

Admin Task

Define security groups

Add or Edit Security Groups

Define roles

Add or Edit User Roles

Assign groups to roles

Assign Security Groups to Roles

Assign processes to roles

Assign Processes to Roles or Users

Create users and assign to roles

Edit Users (afm_users table)

Each field in the Archibus schema has an Edit Group (required to change values) and a Review Group (required to see the field at all). A minimum setup can use a single group named % to grant access to everything.

Archibus maintains two identity types:

  • Employee identity (Employees table, sourced from HR)
  • User identity (afm_users, controls login).

They are linked via email address using the Synchronize User and Employee Identities task.

Hierarchical Security – Groups and Access Keys


Roles are key rings.

Groups are individual keys and Groups grant access to Navigator processes and edit/review rights on fields.

Access Key Suffixes

Key

Grants

rev

Review / reporting

ed

Data entry (edit)

cad

CAD plan updating

calc

Result recalculations (e.g., chargebacks)

mgr

Managerial approvals, employee performance

cio

KPI / top-level analysis

Groups are assembled from these keys in order (rev before ed), so lower levels are prefixes of higher levels:

spac-revspac-rev-edspac-rev-ed-mgr

Substring vs. Prefix Matching

Substring rule (with %): User group spac-rev% matches schema groups spac-rev-ed, spac-rev-mgr, etc. Broad, cross-domain grants like %cad% match any group containing "cad".

Prefix rule (no %): User group rplm-rev-ed matches schema groups rplm-rev and rplm-rev-ed, but not rplm-rev-ed-cad (missing the "cad" key).

Common Cross-Domain Wildcard Groups

Group

Grant Access To

%rev%

All review tasks

%rev-ed%

All review and edit tasks

%cad%

All CAD tasks

%mgr%

All managerial tasks

%cio%

All CIO/KPI tasks

%dba%

All DBA tasks

%sysint%

All System Integrator tasks

Domain-Specific Examples

Space (spac): spac% (all) · spac-rev · spac-rev-ed · spac-rev-ed-cad · spac-ep (Emergency Prep) · spac-ep-rev-ed-rt-mgr

Real Property (rplm): rplm% · rplm-rev · rplm-rev-ed · rplm-rev-ed-cad · rplm-rev-ed-calc

Building Ops (bops): bops% · bops-rev-ed-cf (craftspersons) · bops-rev-ed-cf-mgr · bops-rev-ed-cf-admin

System (sys): sys% · sys-dba · sys-dba-pers · sys-dba-pers-sysint

Virtual Private Archibus (VPA)


The Virtual Private Archibus (VPA) restriction is an SQL restriction attached to the current user session. VPA is a part of the Archibus data security.

VPA Groups (Recommended for Complex Deployments)

Enable via the AbSystemAdministration-UseVpaGroups preference. When enabled, existing Building/Site Code Lists and role-level VPA Restrictions are ignored.

VPA Groups are centralized, expression-oriented, and combinable — often reducing hundreds of roles to tens of roles.

Key mapping tables

Table

Maps VPA Groups To

vpa_groupstoroles

Roles

vpa_groupstousers

Users

vpa_bl

Buildings

vpa_site

Sites

vpa_legal

Legal entity IDs

Sample VPA Groups: GEO-US-EAST (Regional: US East Coast), GEO-US-WEST (US West Coast), GEO-EU (Europe), CSR-ALL-CRMS (All Customers).

Field-Type VPA Restrictions

Applied directly on a role's VPA Restriction field as XML. Filters all views containing the named field.

Example — restrict drawings to those starting with "HQ":

<restriction type="forFields" sql="#ASQL_VPAField() LIKE 'HQ%'"> 
      <title translatable="true">Fields-Named Restriction on dwg_name</title> 
      <field name="dwg_name"/> 
</restriction>
Example — restrict to Voice telecom service:
<restriction type="forFields" sql="#ASQL_VPAField() = 'V' "> 
     <title translatable="true">Fields-Named Restriction on tc_service</title> 
     <field name="tc_service"/> 
</restriction>

Custom SQL with VPA Macros

For custom views, use ${sql.getVpaRestrictionForTable('tablename')} in JOINs and ${sql.vpaRestriction} in WHERE clauses:

<sql dialect="generic"> 
        SELECT project_id, project_name, ... 
        FROM project 
        LEFT OUTER JOIN bl ON bl.bl_id = project.bl_id 
           AND ${sql.getVpaRestrictionForTable('bl')} 
        LEFT OUTER JOIN program ON program.program_id = project.program_id 
           AND ${sql.getVpaRestrictionForTable('program')} WHERE ${sql.vpaRestriction} 
</sql>

Requirements Template


Role Definition

Field

Value

Role Name / Code

(e.g., 2-VPA-MGR-GEO-US-EAST)

Description

(responsibilities)

License Level

(Activity ACP / Process Owner)

User Population

(count, provisioning method)

Assigned Processes

(Navigator menu items)

Group Assignments

Group Code Target Purpose
spac-rev-ed Prefix Review + edit for Space Management
bops-rev Prefix Review-only for Building Ops
%cio% Substring Cross-domain KPI access

VPA Restrictions

Approach Group / Restriction Target
VPA Group GEO-US-EAST via vpa_site Site-level
Field-type #ASQL_VPAField() LIKE 'HQ%' dwg_name field

Deliverables Checklist


  • Role inventory with group assignments and VPA restrictions
  • VPA mapping tables populated (if using VPA Groups)
  • Authentication and provisioning decisions documented
  • Employee-to-User identity sync confirmed
  • Exception process defined
  • Security review cadence agreed
  • Test plan per security group
  • IT Security / Compliance sign-off