> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elementum.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Object Data Access
> Control who can view and edit records on an object through dynamic access policies and per-record sharing
## Overview
Data Access controls who can view and edit **records** within your Elementum applications through two complementary systems:
* **Policy-Based Access** — Dynamic access policies that determine which records users can see based on user roles, record criteria, and contextual conditions. Policies apply filtering rules across all records in an Object.
* **Access Sharing** — Grants specific users or groups access to individual records through auto-sharing triggers or manual shares, providing record-level access control.
Data Access applies to records across all Object types: 
Apps, 
Elements, 
Tasks, and 
Tables.
Instead of static permissions, Data Access creates dynamic filters that evaluate in real-time based on current user context and record data.
***
## Creating Access Policies
1. Go to your **App** navigation
2. Under **Security**, click **Data Access**
3. Click **+ Policy** to create a new access policy
1. Choose **Users and Groups** that this policy applies to
2. Use the dropdown to select specific users or user groups
3. Multiple users and groups can be added to a single policy
Users can be part of multiple policies. The system combines access from all applicable policies.
Define when users should have access to records:
1. Click **Give access when** to start building conditions
2. Select the field to filter on
3. Choose the comparison operator
4. Set the value or condition
### Filter Operators
Data Access supports filtering on all data types with appropriate operators for each type:
`contains...`, `starts with...`, `is...`, `is not...`
`equals`, `greater than`, `less than`, `between`
`is after`, `is before`, `is between`, `is in the last X days`
`is empty`, `is not empty`, `is true`, `is false`
The available operators automatically adjust based on the field type you select.
### Default Policy
Every app starts with a default policy that gives Internal Users access to all records. You can modify or delete this default policy as needed.
***
## Current User Variable
You can filter records based on the **current user** viewing the data. This enables scenarios such as:
* Showing users only records assigned to them
* Displaying records where they are mentioned or involved
* Filtering based on user attributes or group membership
### Examples
**Scenario**: Users only see records assigned to them
**Filter Setup:**
* **Field**: `Assigned User`
* **Operator**: `is...`
* **Value**: `Current User`
**Scenario**: Users only see records from their department
**Filter Setup:**
* **Field**: `Department`
* **Operator**: `is...`
* **Value**: `Current User's Department`
**Scenario**: Users see records they created or are assigned to
**Filter Setup (Condition Group):**
* **Condition 1**: `Created By` `is...` `Current User`
* **OR**
* **Condition 2**: `Assigned User` `is...` `Current User`
***
## Advanced Filtering
### Multiple Conditions
1. Click **+ Condition** to add additional filter criteria. Each condition creates an AND relationship by default — all conditions must be true for access to be granted.
2. Click **+ Condition Group** to create OR logic, allowing complex boolean conditions such as "this OR that" scenarios.
3. Use **Clear All** to remove all conditions and start over.
### Complex Access Scenarios
**Scenario**: Sales reps see leads in their territory that are active
**Filter Setup:**
* **Condition 1**: `Territory` `is...` `Current User's Territory`
* **AND**
* **Condition 2**: `Status` `is...` `Active`
Both conditions must be true for access.
**Scenario**: Managers see all records, regular users see only their own
**Policy 1** (Managers):
* **Users**: Manager Group
* **Conditions**: (No conditions — access to all records)
**Policy 2** (Regular Users):
* **Users**: Staff Group
* **Conditions**: `Assigned User` `is...` `Current User`
**Scenario**: Users see records created in the last 30 days that involve them
**Filter Setup:**
* **Condition Group 1**:
* `Created By` `is...` `Current User`
* **OR**
* `Assigned User` `is...` `Current User`
* **AND**
* **Condition 2**: `Created Date` `is after...` `30 days ago`
***
## Managing Access Policies
In the **Data Access** section, you can:
* View all active policies and their assigned users/groups
* Edit existing policies by clicking the edit icon
* Delete policies that are no longer needed
* Test policies to verify they work as expected
***
## Access Sharing
Access Sharing provides record-level access control, allowing you to grant specific users or groups access to individual records. While policy-based access applies filtering rules broadly, Access Sharing gives precise control over who can access each specific record.
Access is granted through two mechanisms:
* **Auto-Sharing** — Automatically grants access when users interact with records (becoming watchers, approvers, assignees, or being mentioned)
* **Manual Sharing** — Explicitly grant or revoke access to specific users or groups for individual records
Policy-based access determines "Can this user see records that match these criteria?" while Access Sharing determines "Can this specific user see this specific record?" Both systems work together — a user may gain access through policies, sharing, or both.
### Auto-Sharing Triggers
Auto-sharing automatically grants record access to users based on their interactions with the record. App Admins can enable or disable each trigger type independently.
When a user is added as a watcher to a record, they automatically gain access. Watchers typically receive notifications about record changes and updates.
**Use case**: Enable for support teams who need access to cases they're monitoring.
When a user is added to an approval workflow for a record, they automatically gain access to review and approve that record.
**Use case**: Enable for approval processes where approvers need to view record details.
When a user is @mentioned in a comment or description on a record, they automatically gain access to view the context of the mention.
**Use case**: Enable for collaborative environments where team members reference each other.
When a user is assigned to a record as an individual assignee, they automatically gain access to work on that record.
**Use case**: Enable for task management where assignees need full record access.
When a group is assigned to a record, all members of that group automatically gain access.
**Use case**: Enable for team-based work where entire groups collaborate on records.
Group assignee auto-sharing can grant broad access since all group members receive access. Use cautiously and audit regularly.
#### Configuring Auto-Sharing Triggers
1. Go to your **App** navigation
2. Under **Security**, click **Data Access**
3. Click the **Access Sharing** tab at the top of the page
1. Review the five toggle switches for each trigger type:
* **Watchers**
* **Approvals**
* **Mentions**
* **Individual Assignees**
* **Group Assignees**
2. Toggle each switch to enable (on) or disable (off) that trigger type
3. Each trigger can be controlled independently
1. Changes are saved **immediately** upon toggling
2. Settings apply to **all new actions** in the app going forward
3. Changes are reflected in the **main Object activity log**
4. Existing shares remain unchanged
Auto-sharing only grants access when a trigger is **enabled**. Disabling a trigger prevents new automatic sharing, but existing shares from past actions remain until manually removed.
### Access Audit Page
The Access Audit Page shows all users and groups who have access to records in your app through auto-sharing or manual shares.
To access it, go to your **App** navigation, then under **Security**, click **Data Access** and select **Audit Page**.
The audit page displays:
* All users and groups with record access
* The number of records each user or group has access to
The Audit Page shows access grants from Access Sharing only. Users may have additional access through policy-based Data Access.
#### Reviewing and Removing Access
From the **Audit Page**, click on a user or group to open a modal with their access details, including the list of records, access source (trigger type or manual share), and a search field to filter by name or handle.
1. Locate the record you want to revoke access to
2. Click the **remove** or **revoke access** button next to the record
3. Confirm the removal when prompted — access is revoked immediately
Removing access immediately affects the user's ability to view and interact with the record. If a user regains access through an enabled auto-sharing trigger (e.g., being reassigned), they will receive access again automatically.
### External Tag on a Record
The **External** tag next to a record's handle indicates that the record has been shared with at least one external user, either directly or through a group that includes one. It is a privacy indicator that someone outside your company can see the record.
#### How a user is classified as external
Internal versus external classification is driven by **email domain**. An Org Admin configures which domains are treated as internal (for example, `@yourcompany.com`). Any user whose email is on a domain that is not on that list — for example, an invited supplier or partner — is flagged as external, even though the user is still a member of your Elementum organization. See [System-managed Groups](/administration/groups#system-managed-groups) for how the **External Users** group is maintained.
#### What to keep in mind
* Classification is based on email domain and your org's configured internal-domain list, not on which company a user "really" belongs to.
* If a legitimate company domain has not been added to the internal list, your own employees can appear as external. If you see the **External** tag on a record that is only shared with colleagues, the internal-domain configuration usually needs updating — it does not necessarily mean an outside party has access.
***
## Best Practices
Always test your access policies before deploying to production to ensure users can access the data they need.
* **Start restrictive** — Begin with limited access and add permissions as needed rather than starting permissive
* **Audit regularly** — Periodically review access policies to ensure they still align with business needs
* **Document policies** — Record why specific access policies were created and their intended purpose
* **Test from user perspectives** — Verify policies from different user roles to ensure the experience is intuitive
### Common Pitfalls
**Problem**: Users can't access data they need for their job
**Solution**:
* Use condition groups to create multiple access paths
* Consider user workflows when designing policies
* Test with actual user scenarios
**Problem**: Multiple policies create unexpected access patterns
**Solution**:
* Document policy interactions
* Use clear naming conventions for policies
* Conduct regular policy reviews and cleanup
**Problem**: Complex policies slow down data loading
**Solution**:
* Keep conditions simple when possible
* Index fields used in access policies
* Monitor system performance after policy changes
***
## Troubleshooting
### Users Can't See Expected Data
1. Verify the user is included in the correct policy groups
2. Ensure filter conditions match the actual data values
3. Verify that user attributes (used in Current User variables) match expected values
4. Review all policies that might apply to the user
### Policy Not Working as Expected
**Check**: Verify AND/OR logic between conditions
**Solution**: Use condition groups to create proper boolean logic
**Check**: Ensure filter values match field data types
**Solution**: Verify text fields use text operators, dates use date operators, etc.
**Check**: Verify user has the required attributes set
**Solution**: Update user profiles with necessary field values