Why Access Control Matters for Insights

A single insight is generated once per record per agent run. Insights are not generated separately for each user - they are shared. The same Insight Result record is read by many users.

Because an insight may combine data from multiple Salesforce records and fields, a user looking at it may end up seeing information they would not be able to access if they queried those records and fields directly. Without access controls, a user could view AI-generated insights about Opportunities they cannot read, fields they do not have field-level security for, or accounts in another business unit.

Insight access control closes that gap. It ensures that a user can only see an insight if they have legitimate access to all of the underlying records and fields that contributed to it.

Enabling RBAC on Insights

Insight access control is activated by a single setting: set the Insight Result object's internal sharing model to Private in Salesforce Setup. Once that is done, Precursive AI automatically enforces the access checks described in this article.

If the sharing model is left at Public Read or Public Read/Write, the access control layer is bypassed and all users with the Precursive AI Standard permission set can see all insights. If your org needs RBAC on insights, set the sharing model to Private.

The rest of this article applies only when the sharing model is Private.

The Four-Layer Access Model

Access to an insight is controlled at four layers, all of which must be satisfied for a user to see an insight.

• Layer 1 - Object Permission: The user must have the Precursive AI Standard permission set assigned. This grants read access to the Insight Result object. Without this permission set, the Precursive AI component is not visible to the user at all.
• Layer 2 - Field-Level Security: The user must have read access to all fields used in the insight's context. If a user lacks field-level security (FLS) on even one field referenced in the insight, access is denied.
• Layer 3 - Record Sharing: The user must have an explicit share record on the specific Insight Result. This is created either proactively for batch runs or reactively on demand - see "How Access Is Granted" below.
• Layer 4 - Context Record Access: The user must have record-level access to all Salesforce records referenced in the insight's context. If they cannot read even one of the source records, access is denied.

How Access Is Granted

There are exactly two ways a user can be granted access to an insight. Both produce share records on the Insight Result, but they are triggered differently.

Share Groups (Proactive, Batch Runs)

Use Share Groups when you want to pre-share insights with a known group of users at the time the insight is generated. This is helpful when you have a team that should always see insights from a given agent without each member having to navigate to the record first.

When the scheduled batch generates insights, the system checks each member of the configured Share Groups and each email digest recipient. For each user, it verifies whether they pass the Layer 3 and Layer 4 checks (field-level security and record access). If they pass, a share record is created. If they fail, no share is created.

To configure Share Groups:

1. Open the Zen Agent record
2. Locate the Share Groups field
3. Enter the DeveloperNames of the Salesforce Public Groups whose members should be evaluated for access. Use a comma-separated list. Example: Insight_Viewers,Sales_Team
4. Save the record

Share Groups use Public Group DeveloperNames rather than IDs, which makes the configuration portable across sandbox and production environments.

There are two share record types created by batch runs:

• Group Access - created for Share Group members who pass the access check
• Distribution Recipient - created for email digest recipients who pass the access check

On-Demand Verification (Reactive)

Not every user who should see an insight will be in a Share Group, and that is fine. For users who have the Precursive AI Standard permission set but no existing share record, access is verified at the moment they navigate to a record page that includes the Precursive AI component.

When the component loads, the system runs a real-time check against all context records and fields referenced by the insight. If the user passes, a Verified Access share record is created immediately and the insight is displayed. If they fail, the component shows an access denied message.

This means you do not need to predict every potential viewer in advance - access is evaluated when it is needed.

Insights Generated via Refresh or Preview

When an insight is generated outside of a scheduled batch (via the Refresh button on the component or the Preview action on the Zen Agent), the batch sharing path is bypassed. Whoever triggered it gets access through on-demand verification when they view the result.

Known Limitation: Access Reduction Is Not Retroactive

When a user's access to underlying records or fields is reduced after a share record has already been created for them, the existing share record is not automatically removed. The user will continue to see the insight until either the share record is manually revoked or the insight is regenerated and a fresh access check is performed.

In practice, this means that a regular cadence of agent runs (which generate fresh insights and fresh access checks) will naturally reset access over time, but there is no real-time clawback when permissions change.

Troubleshooting Access Issues

Access Check Log

Each Insight Result record includes an Access Check Log field that captures an audit trail of all access grant and deny decisions for that insight. This is the first place to look when a user reports they cannot see an insight they expect to have access to.

The log shows which users were checked, whether they passed or failed the access verification, and the reason for any denial. This helps you quickly identify whether the issue is a missing permission set, a record sharing gap, or a field-level security restriction.

When a User Sees an Access Denied Message

If a user views a record page and the component displays an access denied message, the real-time context access check determined that the user does not have access to one or more of the records or fields used to generate the insight.

Steps to investigate:

1. Open the relevant Insight Result record
2. Review the Access Check Log to identify what access check failed
3. Check whether the user has the Precursive AI Standard permission set
4. Check whether the user has record access to the source records referenced in the insight
5. Check whether the user has field-level security for the fields used in the insight context

If the user's access is correct and they should be able to see the insight, re-running the insight via the Refresh button will trigger a fresh access check and create a Verified Access share record if they now pass.