Access Control Overview

Overview

Entegrata’s access control system works hand-in-hand with our data mapping platform to secure your data. Access control data can be ingested from supported data sources into our standardized models, or you can manage new controls directly in our platform. This centralized management and observability gives you a single pane of glass view into data security across your entire data footprint, making it easy to audit permissions, troubleshoot access issues, and ensure the right people see the right data in the edges supported by Entegrata (i.e Power Bi).

Key Features

Default Permissions

Set entity-level default access permissions that apply to all resources of a specific data type

Rule Management

Create granular access rules with subject and object targeting for precise permission control

Group Management

Organize users into groups with static or dynamic membership for efficient access management

Permission Testing

Test and explore permissions to verify access configurations before deployment

Availability and Prerequisites

Access control features require specific prerequisites to be met before they become available. This section outlines what’s needed for each surface area.

Top-Level Requirement

Production Pipeline Required: Access control only works when the “main” production pipeline exists. Below, find additional prerequisites per feature area.

Supported Entities

Access control rules (both System and Ingested) are available for the following canonical data mappings:

Client

Client entity data mappings

Matter

Matter entity data mappings

Person

Person entity data mappings

Prerequisites by Feature

Groups Management
Rules Management
Access Control Ingestion

Prerequisites for managing access control groups and actors:To access the Groups and Actors pages:

The Person entity must be mapped and deployed

To properly identify actors in your entity OBTs (One Big Tables), the Employment entity must be deployed with the Entra data source as a source that maps Entra’s userPrincipalName field to the canonical username field.

Prerequisites for enabling access control data ingestion from data sources:

Actor Resolution Requirement: For any actor resolution to take place on ingested rules and groups, each data source must be mapped in the Person entity in addition to mapping in Client and/or Matter entities. Without a Person entity mapping for the data source, the system cannot resolve which actors the ingested permissions apply to.

Entra (Microsoft Graph)

Required entity mappings:

Person entity must be mapped and deployed
Employment entity must be mapped and deployed

Mapping Expectations:

Map Person entity from the Entra users table
Map Employment entity from the Entra users table

Important: Entra should map userPrincipalName to Employment username for OBT (One Big Table) usage. Otherwise, the principal name’s in the OBTs will fall back to the email field on the Person entity.

Aderant

Required entity mappings:

Person entity must be mapped and deployed
Client entity must be mapped and deployed
Matter entity must be mapped and deployed

Additional requirement: The CMS_SECURE_ROW table with the REVOKED flag and its parent CMS_SECURE_PLAN table must contain valid access control data.Mapping Expectations:

Map Person entity from the Aderant HBM_PERSNL table
Map Client entity from the Aderant client table (typically HBM_CLIENT)
Map Matter entity from the Aderant matter table (typically HBM_MATTER)

Intapp Walls

Required entity mappings:

Person entity must be mapped and deployed
Client entity must be mapped and deployed
Matter entity must be mapped and deployed

Additional requirement: The Generic Extension must be enabled in your Intapp Walls application.Mapping Expectations:For each entity, configure the Intapp Walls data source with proper key matching to your primary source (typically Aderant):Person Entity Mapping:

Set EntityId as the Intapp Walls primary key
Join on your primary Person source (e.g., HBM_PERSNL)
Match Intapp Walls identifiers (FinancialSystemId, EntityCustomData) to your primary source fields (EMPL_UNO, EMAIL)

Client Entity Mapping:

Set EntityId as the Intapp Walls primary key
Join on your primary Client source (e.g., HBM_CLIENT)
Match Intapp Walls EntityRemoteSystemId to your primary source client identifier (CLIENT_NUMBER)

Matter Entity Mapping:

Set EntityId as the Intapp Walls primary key
Join on your primary Matter source (e.g., HBM_MATTER)
Match Intapp Walls FinancialSystemId to your primary source matter identifier (CLIENTS_MATTER_NUMBER)

Rule Types

System Rules & Groups
Ingested Rules & Groups

Available for: Client, Matter, and Person entitiesOnce prerequisites are met for an entity:

Create custom access rules directly in Entegrata
Build groups with static or dynamic membership
Define granular permissions for your data
Layer controls on top of any existing permissions

System rules provide full control and can be edited or deleted at any time.

Critical: All canonical objects default to Deny (false) permissions. After mapping data sources, you must review and adjust default permissions to ensure users have appropriate base-level access.

Core Concepts

Permission Model

The Entegrata Access Control system uses a hierarchical permission model:

Default Permissions - Base-level permissions applied to all resources of an entity type
Rule-Based Permissions - Specific rules that override defaults for targeted subjects and objects
Permission Precedence - More specific rules take precedence over general ones

Key Terminology

Actor

concept

An individual user in the system who can be granted access permissions

Subject

concept

An actor or group that permissions are applied to (who has access)

Object/Resource

concept

The data entity or specific record being accessed (what is being accessed)

Entity

concept

A canonical data type in your Lakehouse (e.g., Client, Matter, Timekeeper)

Rule

concept

An access control policy that defines permissions for specific subjects and objects

Group

concept

A collection of actors that can be managed together for access control purposes

How Access Control Works

Verify Main Pipeline Exists

Ensure your main production pipeline is deployed and has completed at least one successful run. Access control features are only available after this prerequisite is met.

Map Data Sources to Canonical Objects

Complete data mapping configuration for Client, Matter, and Person entities. Deploy these entity mappings and ensure the main pipeline processes them successfully.

Review Default Permissions

Check and configure default permissions for each entity. Important: All entities default to Deny (false), so this step is critical to ensure proper base-level access.

Enable Access Control Ingestion (Optional)

For Aderant or Intapp Walls data sources, optionally enable access control synchronization to import existing rules and groups from these systems (requires specific entity prerequisites).

Create Access Groups

Organize users into groups for efficient permission management, using either static membership or dynamic filters. Requires Person entity to be deployed. For best actor identification, also map Employment with Entra for UPN-to-username mapping.

Define Access Rules

Create system rules to implement your access control requirements, layering custom permissions on top of defaults and any ingested rules. Requires Person entity to be deployed and run for subject data.

Test Permissions

Use the comprehensive testing tools to verify that permissions work as expected before rolling out to users.

Monitor and Adjust

Use exploration features to review access patterns, audit permissions, and refine your configuration over time.

Common Use Cases

Legal Data Security

Restrict matter access to assigned attorneys and staff
Implement ethical walls for conflict management
Control access to sensitive client information

Compliance Requirements

Enforce data residency and jurisdiction rules
Maintain audit trails of access permissions
Implement need-to-know access policies

Organizational Hierarchy

Grant department-level access to relevant data
Implement role-based access control (RBAC)
Manage temporary access for consultants

Best Practices

Start with Deny, Grant Explicitly: Law firms require strict data security. Begin with restrictive defaults (Deny) and explicitly grant access where needed. This ensures no accidental data exposure.

Use Groups Effectively: Create logical groups that reflect your organizational structure to simplify permission management.

Test Before Production: Always use the permission testing tools to verify access configurations before applying them to production data.

Document Your Rules: Use descriptive names and descriptions for rules to make their purpose clear to other administrators.

Next Steps

Enable Access Control

Learn how to enable access control for your data sources

Configure Permissions

Set up default permissions for your entities

Create Your First Rule

Build custom access rules for specific scenarios

Explore the System

Use testing tools to understand permission flows

Need Help?

If you encounter issues or have questions about access control configuration:

Contact Entegrata Support
Review the troubleshooting guide
Schedule a consultation with your Customer Success Manager

Getting Started

Essential Configuration

Access Management

Optional Features

Testing & Validation

Overview

Key Features

Default Permissions

Rule Management

Group Management

Permission Testing