Skip to main content

Overview

Access control rules allow you to define specific permissions that override default settings for targeted subjects (users or groups) and objects (resources). Rules provide granular control over who can access what data, supporting both simple static assignments and complex dynamic filters for automatic permission management.

Understanding Rules

Rule Components

Every access control rule consists of four key components:
General Settings
component
  • Name: Descriptive identifier for the rule
  • Description: Explanation of the rule’s purpose
  • Permission: Allow or Deny access
Subject (Who)
component
The users or groups that the rule applies to:
  • Specific Users: Individual actors selected by name
  • Groups: Access control groups containing multiple users
  • Dynamic Filters: Attribute-based selection using filter conditions
Object (What)
component
The resources that the rule governs:
  • All Resources: Rule applies to entire entity type
  • Specific Resources: Individual records selected by ID
  • Filtered Resources: Dynamically selected using attribute filters
Scope
component
  • Entity Type: The canonical object type (Client, Matter, etc.)
  • Instance: Applied within your Entegrata instance

Creating a Rule

Step 1: Navigate to Rule Creation

Rules can be created by following these steps:
  1. Go to DataMapping
  2. Click the Access Control tab
  3. Click Create Rule in the toolbar
Access Rules table showing mix of system and ingested rules

Step 2: Configure General Settings

The Rule Modal opens with the General tab active:
Rule Modal - General tab
1

Enter Rule Name

Provide a clear, descriptive name that explains the rule’s purpose
  • Good: “Finance Team - Budget Access”
  • Poor: “Rule 1” or “Test”
2

Add Description

Write a detailed explanation of why this rule exists and what it accomplishes
3

Set Permission

Toggle the permission setting:
  • Allow (Green): Grants access to specified resources
  • Deny (Red): Blocks access to specified resources
The modal background changes color (green for Allow, red for Deny) to provide visual confirmation of the permission setting.

Step 3: Define Subjects (Who Has Access)

Click the Subject tab to specify who this rule applies to:
Rule Modal - Subject tab
You can add users (actors) directly to rules without creating groups. Groups are optional but recommended for managing multiple users efficiently.

Option 1: Select Specific Users (Actors)

Add individual users directly to the rule:
  1. Click the Users dropdown
  2. Search for users by name
  3. Select users as needed
  4. Selected users appear as tags
This approach works well for:
  • Small numbers of users
  • Temporary or one-off access
  • User-specific exceptions
User selection dropdown with search
Use groups to manage multiple users more efficiently:
  1. Click the Groups dropdown
  2. Search for access control groups
  3. Select groups as needed
  4. All group members inherit the rule permissions
Benefits of using groups:
  • Easier to manage multiple users
  • Changes to group membership automatically update access
  • Cleaner rule configuration
  • Better organization of permissions
Group selection dropdown

Option 3: Use Dynamic Filters

For automatic subject selection based on attributes:
  1. Click Add Filter Condition
  2. Select the attribute to filter on
  3. Choose the operator (equals, contains, etc.)
  4. Enter the comparison value
  5. Add additional conditions with AND/OR logic
Subject filter builder interface
Dynamic filters automatically apply to new users matching the criteria, reducing maintenance overhead.

Step 4: Define Objects (What They Can Access)

Click the Object tab to specify which resources the rule covers:
Rule Modal - Object tab

Option 1: All Resources

Leave the resource selection empty to apply the rule to all resources of the entity type.

Option 2: Specific Resources

  1. Click the Resources dropdown
  2. Search for specific records by name
  3. Select resources as needed
  4. Selected resources appear as tags
Resource selection dropdown

Option 3: Filtered Resources

For dynamic resource selection:
  1. Click Add Filter Condition
  2. Select the resource attribute
  3. Choose the comparison operator
  4. Enter the value to match
  5. Combine conditions as needed
Object filter builder interface
Example filters:
  • Status equals Active
  • Department contains Legal
  • CreatedDate after 2024-01-01

Step 5: Preview Rule Impact

Click the Explore tab to preview which subjects and objects will be affected: The exploration shows:
  • Affected Subjects: Count and list of users/groups
  • Affected Objects: Count and list of resources
  • Effective Permissions: Resulting access levels
Rule Modal - Explore subjects tab
Rule Modal - Explore objects tab
Always review the exploration results before saving to ensure the rule affects only the intended subjects and objects.

Step 6: Save the Rule

  1. Review all settings across tabs
  2. Click Save to create the rule
  3. Monitor the save progress:
    • Compiling → Validating → Syncing

Understanding Rule Types

System (Native) vs Ingested Rules

Entegrata displays two types of rules in your access control configuration:
What are System Rules? System rules are created directly by administrators within Entegrata. These are fully manageable and form your custom access control layer on top of any ingested permissions.Characteristics:
  • Created by administrators in Entegrata
  • Fully editable and deletable
  • Display with standard formatting (white background)
  • Show “System” in the Source column
  • Can be modified at any time
Management:
  1. Click on the rule row to open for editing
  2. Modify any settings as needed
  3. Save changes or delete if no longer needed
  4. Changes take effect immediately
The visual distinction (blue background tint) helps you quickly identify which rules are managed in Entegrata versus those synchronized from external systems.

Editing Rules

Making Changes

To edit an existing system rule:
  1. Navigate to the rule list
  2. Click on the rule you want to edit
  3. The Rule Modal opens with current settings
  4. Make necessary changes
  5. Click Save to apply updates
Changes to rules take effect immediately but may require 1-2 minutes to fully propagate across the system.

Deleting Rules

To delete a system rule:
  1. Find the rule in the rules table
  2. Click the Delete action button
  3. Confirm deletion in the dialog
  4. The rule is removed immediately
Delete confirmation dialog
Deleting a rule immediately removes all permissions it granted. Ensure alternative access is available if needed.

Rule Management Best Practices

Naming Conventions

Establish consistent naming patterns:
  • [Department] - [Resource Type] - [Access Level]
  • [Project] - [Team] - [Permission Type]
  • [Compliance] - [Regulation] - [Restriction]
Examples:
  • “Legal - Active Matters - Full Access”
  • “Project Alpha - Development Team - Read Only”
  • “SOX - Financial Data - Restricted”

Organization Strategies

Use Groups: Create rules for groups rather than individuals to simplify management and reduce rule count.
Layer Rules: Start with broad rules, then add specific exceptions. This creates a clear permission hierarchy.
Document Purpose: Always fill in the description field to explain why the rule exists and when it should be reviewed.
Regular Reviews: Schedule periodic reviews of rules to remove obsolete ones and update as needed.

Filter Best Practices

When using dynamic filters:
  1. Test Thoroughly: Use the Explore tab to verify filter results
  2. Avoid Over-Complexity: Simple filters are easier to understand and maintain
  3. Consider Performance: Very complex filters may impact evaluation speed
  4. Document Logic: Explain filter conditions in the rule description

Advanced Rule Patterns

Pattern 1: Department-Based Access

Scenario: Grant department members access to their department’s data Implementation:
  • Subject Filter: Department equals "Finance"
  • Object Filter: OwnerDepartment equals "Finance"
  • Permission: Allow

Pattern 2: Time-Based Access

Scenario: Temporary access for consultants Implementation:
  • Subject: Specific consultant group
  • Object Filter: ProjectEndDate after TODAY
  • Permission: Allow
  • Review regularly to remove expired access

Pattern 3: Hierarchical Access

Scenario: Managers access their team’s data Implementation:
  • Subject Filter: Role contains "Manager"
  • Object Filter: TeamId in [managed_teams]
  • Permission: Allow

Pattern 4: Compliance Restrictions

Scenario: Implement ethical walls Implementation:
  • Subject: Restricted user group
  • Object: Specific conflicted matters
  • Permission: Deny
  • Higher precedence than allow rules

Rule Precedence and Conflicts

When multiple rules apply to the same subject and object:
1

Most Specific Wins

Rules targeting specific users override group rules Rules targeting specific resources override filtered resources
2

Deny Overrides Allow

If both Allow and Deny rules apply at the same specificity level, Deny wins
3

Entity Defaults Apply Last

Default permissions only apply when no specific rules match

Conflict Resolution Example

Given these rules for User A accessing Resource X:
  1. Default: Allow (entity level)
  2. Rule 1: Deny for Group B (User A is member)
  3. Rule 2: Allow for User A specifically
Result: User A has access (specific user rule overrides group rule)

Troubleshooting Rules

Common Issues

  • Allow 1-2 minutes for propagation
  • Verify subject and object selections
  • Check for conflicting higher-precedence rules
  • Test using permission explorer
  • Review filter conditions carefully
  • Check group membership if using groups
  • Verify attribute values in source data
  • Test filters with different operators
  • Look for deny rules with higher precedence
  • Check if default permissions changed
  • Verify user group memberships
  • Use permission testing to trace the denial source
  • Simplify complex filter conditions
  • Reduce number of OR conditions
  • Consider splitting into multiple simpler rules
  • Contact support for optimization assistance

Next Steps