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.
Contents
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 ( |
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 |
|---|---|
|
|
Review / reporting |
|
|
Data entry (edit) |
|
|
CAD plan updating |
|
|
Result recalculations (e.g., chargebacks) |
|
|
Managerial approvals, employee performance |
|
|
KPI / top-level analysis |
Groups are assembled from these keys in order (rev before ed), so lower levels are prefixes of higher levels:
spac-rev → spac-rev-ed → spac-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 |
|---|---|
|
|
All review tasks |
|
|
All review and edit tasks |
|
|
All CAD tasks |
|
|
All managerial tasks |
|
|
All CIO/KPI tasks |
|
|
All DBA tasks |
|
|
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
Learn more
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 |
|---|---|
|
|
Roles |
|
|
Users |
|
|
Buildings |
|
|
Sites |
|
|
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
See Also
If you also want to refine your security further, thenrefer to the other sections of the help that cover authentication, hierarchical security, and the virtual private Archibus data partitioning features.
- Hierarchical Security Overview
- Application-Level Virtual Private Archibus
- How to Enter a VPA Restriction for a Field
- Default Site and Building Code VPA Restrictions in the Archibus Users Table
- How to Enter an SQL-Type VPA Restriction on a Table
- How to Enter an SQL-Type VPA Restriction for a Validated Table
- How to Set Up a VPA by Building in the Archibus Users Table
- VPA Restrictions and Custom Data Access
- Assigning VPA Groups Using Mapping Tables
- Considerations for Group VPAs
- VPA Groups: Use Cases
- Archibus Administrator: User and Security Process
- Getting Started with Roles, Users, and Processes
- Add a New Security Group
- Add a New User
- Example of Using Security on a Database Field
- Working with User Roles
- Controlling Background Data Tasks
- View-Level Security
- Securing Web Central for Production Deployments
- Advanced Application Security
