Property-Based Access Control
Property-Based Access Control (PBAC) helps you manage who can access specific records based on your business classifications. Instead of relying only on user roles, PBAC uses the properties on a record, such as its group, category, or region, to decide what a user can see or edit. This gives you more precise control over sensitive or restricted data.
You define business properties (like Company Group, Contract Group, or Country), and the system evaluates user access based on those property values.
Here are a few examples of business properties you may manage:
- Company Group: Public, Internal, Training, Restricted
- Contract Group: Standard, Strategic, High-Risk
- Country: India, US, Germany
These properties are modeled as dedicated Property Object in the Schema defined in the Conga Advantage Platform. Other objects (such as Account, Agreement, Supplier) reference these Property Objects via lookup fields. PBAC then uses the property values on those objects to decide whether a user is allowed to Read, Create, Update, or Delete a record.
A Property Object is a special type of
object in the Conga schema, identified by ObjectType = Property. It represents a master
data domain (for example, Company Group) and contains records
representing each allowed value (Public, Internal, Training, Restricted, etc.).
As an administrator, you don't need to configure code or technical rules. Instead, you work with familiar classifications and permission groups that reflect your organization's structure. PBAC then evaluates these settings whenever a user tries to read, create, update, or delete a record. This ensures that only the right people can work with the right data.
How PBAC fits into your existing permissions
PBAC works together with your existing Role-Based Access Control (RBAC):
RBAC determines what a user can do at a high level, such as creating or editing a type of record.
PBAC narrows that down by checking the record's business property. For example, a user may have permission to edit Agreements in general, but PBAC ensures they can only edit Agreements marked as "Internal," not "Restricted."
This pairing gives you broad control through roles, and precise control through business properties.
How PBAC uses business properties
PBAC evaluates permissions based on the property value stored on a record. These properties, such as Company Group or Country, are standardized across the platform so they can be used consistently in different modules.
When a user tries to view or work with a record, PBAC checks:
- The user's object-level permissions (from roles).
- The property value assigned to that record.
Whether the user's permission group is allowed to work with that specific property value.
PBAC evaluates permissions on:
- First-Level
PBAC objects – objects that directly reference a Property
Object. For example,
Accounthas a lookup toCompany Groupproperty object. - Second-Level
PBAC objects – objects that reference a 1st-level object which
itself references a Property Object. For example,
AgreementLineItemreferences Agreement, and Agreement references theContract GroupProperty Object.
The Conga platform supports permission resolution up to two levels.
How PBAC is applied at runtime
First-level PBAC objects:
A first-level PBAC object is any object that has a direct lookup to a Property Object. For example:
Accounthas a lookup toCompany Group.Agreementhas a lookup toContract Group.
For these objects, PBAC is evaluated on every CRUD operation:
- Create /
Update / Delete
- RBAC: User must have object-level permission to perform the operation.
- PBAC: The Property value set on the record must allow that action (e.g., Create or Update) for the user's permission group for that specific property value.
- Read (Query)
- RBAC: User must have permission to read the object (directly or via scope).
- PBAC: Only records with property values where Read is allowed will be returned.
Second-level PBAC objects:
A second-level PBAC object references a first-level object that references a Property Object. For example:
Agreementreferences Account, and Account references theCompany GroupProperty Object.AgreementLineItemreferences Agreement, and Agreement references theContract GroupProperty Object.
In this case:
- The second-level object's access is evaluated based on the property value on the related first-level object, not directly on the second-level object.
Consider a scenario where an
Agreementis linked to anAccountthat has aCompany Groupproperty value of Internal. In this case, the permission to read theAgreementis determined by theCompany Groupproperty value on the relatedAccount. If the user's permission group allows access to "Internal" records, they will be able to read theAgreement. This indirect evaluation ensures that permissions are consistently applied across related objects.