Loading

Error CANNOT_EXECUTE_FLOW_TRIGGER during NPSP Batch Jobs after User License Downgrade

Дата публикации: Jul 29, 2026
Описание

Symptoms

Administrators will typically observe the following indicators:

  • Mass error entries appearing in the NPSP Error Log, concentrated during the nightly batch window (commonly around 2:00–2:15 AM local time).
  • Error count can reach thousands or tens of thousands of affected records per run.
  • Contact Hard Credit rollups, Account Soft Credit rollups, and other NPSP Customizable Rollup calculations stop processing.
  • Record-Triggered Flows that reference cross-object fields (e.g., Account.npe01__One2OneContact__c) begin failing on records touched by the batch process.

 

Error Message

The error logged in the NPSP Error Log and/or Apex exception emails will follow this pattern:

 

CANNOT_EXECUTE_FLOW_TRIGGER

We encountered an error when evaluating the formula for the entry criteria of the [Flow_API_Name] flow.

Tell your Salesforce admin about this error: Could not access the following field: Account.npe01__One2OneContact__c

Context: CRLP.ContactHardCredit

The field reference in the error message may vary depending on which Flow’s entry criteria references cross-object NPSP fields. Common examples include Account.npe01__One2OneContact__c, Account.npe01__SYSTEMIsIndividual__c, or any custom cross-object formula used in a Record-Triggered Flow’s Start Element.

 

Root Cause Analysis

This error is caused by a collision between Salesforce’s Scheduled Job execution context and the security model governing Record-Triggered Flow entry criteria evaluation. The failure chain proceeds as follows:

1. Job Ownership Persistence

When a Salesforce user schedules a batch job (such as NPSP Customizable Rollups, DLRS scheduled calculations, or any Apex Schedulable class), Salesforce permanently binds that job to the scheduling user. The job will continue to execute in that user’s security context indefinitely, regardless of subsequent changes to the user’s license, profile, or permission sets. This binding is visible in Setup > Scheduled Jobs under the "Submitted By" column.

2. License or Profile Downgrade

An administrator changes the job-owning user’s license from a full Salesforce license (e.g., Salesforce Platform, Sales Cloud) to a restricted license type such as "Salesforce Integration" with the "Minimum Access - API Only" profile. This is a common action during employee offboarding or license reclamation. The restricted profile strips visibility to standard objects including Account, Contact, and Opportunity, as well as any custom or packaged fields on those objects.

3. Batch Execution Triggers Flows

When the nightly batch job runs (still executing as the now-restricted user), it performs DML operations on records—typically Contacts or Accounts during rollup calculations. These DML operations fire Record-Triggered Flows configured in the org.

4. Flow Entry Criteria Security Enforcement

Here is the critical failure point. When a Record-Triggered Flow is fired, the Salesforce Flow engine evaluates the Start Element’s Entry Criteria (the conditions that determine whether the flow should run) in the strict security context of the running user—not in System Mode. If the entry criteria contain a cross-object field reference (e.g., Account.npe01__One2OneContact__c on a Contact-triggered flow), the engine checks whether the running user has field-level visibility to that field. Because the restricted user’s profile no longer grants visibility to the Account object or its fields, the Flow engine raises a CANNOT_EXECUTE_FLOW_TRIGGER exception and blocks the entire DML operation.

 

Key distinction: The flow body itself can run in System Mode ("Run in System Context Without Sharing"), but the Entry Criteria evaluation in the Start Element always runs in User Context. This is an intentional Salesforce security design, but it creates a non-obvious failure mode when batch jobs run under restricted users.

Решение

To resolve this issue, the administrator must transfer ownership of the affected scheduled jobs to an active user with full object and field visibility (typically a System Administrator or a dedicated Integration User with an unrestricted profile).

Step 1: Identify the Affected Job Owner

  1. Navigate to Setup > Scheduled Jobs (or search "Scheduled Jobs" in Quick Find).
  2. Locate jobs named "NPSP 02A - Customizable Rollups", "DLRS - Calculate [Rollup Name]", or similar NPSP/DLRS batch entries.
  3. Check the "Submitted By" column. If this column lists the user whose license was recently downgraded, this confirms the root cause.

Step 2: Reschedule NPSP Batch Jobs

  1. Log in as the target System Administrator (or the dedicated Integration User who should own these jobs going forward).
  2. Navigate to the NPSP Settings tab in the App Launcher.
  3. Go to Bulk Data Processes > Batch Process Settings.
  4. Ensure the checkbox "Don’t Auto Schedule Default NPSP Jobs" is unchecked.
  5. Save the settings. Loading and saving this page reschedules the NPSP batch jobs under the currently logged-in user’s context.
  6. Return to Setup > Scheduled Jobs and verify the "Submitted By" column now shows the correct Admin user.

Step 3: Reschedule DLRS Jobs (If Applicable)

If the org uses Declarative Lookup Rollup Summaries (DLRS), those scheduled jobs also need to be transferred:

  1. Navigate to the Manage Lookup Rollup Summaries tab.
  2. For each active rollup summary (especially those targeting Contact or Account objects), click Schedule Calculate.
  3. If a schedule already exists, cancel the existing schedule first, then re-click Schedule Calculate. This forces the job to register under the current user’s context.
  4. Verify in Setup > Scheduled Jobs that the DLRS jobs now show the correct "Submitted By" user.

Step 4: Verify Resolution

After rescheduling, monitor the NPSP Error Log following the next nightly batch run (typically the next morning). The CANNOT_EXECUTE_FLOW_TRIGGER errors should no longer appear, and rollup calculations should process successfully.

Дополнительные ресурсы

Best Practices for Avoidance:

  • Audit Before Downgrading: Before changing a user's license to "Integration" or "Minimum Access," always check Setup > Scheduled Jobs to see if they own critical processes.

  • Use Dedicated Service Accounts: Avoid scheduling system-critical jobs under individual employee users. Use a dedicated "System Admin" generic user for these tasks to prevent issues during staff turnover.

  • Refactor Flow Logic: Avoid complex cross-object formulas in Flow Start Elements (Entry Criteria). Move complex logic to a Decision Element inside the flow, where it runs in System Mode and is less sensitive to user permission quirks.

Optional: Long-Term Architectural Fix

In addition to reassigning job ownership, administrators can make their Record-Triggered Flows resilient against this class of error by refactoring the entry criteria logic:

Problem: Complex cross-object field references (e.g., formulas referencing Account.npe01__One2OneContact__c) in a Flow’s Start Element entry criteria are evaluated in strict User Context.

Fix: Move the complex entry criteria logic out of the Start Element and into a Decision Element immediately inside the flow body.

To implement this:

  • Edit the affected Record-Triggered Flow.
  • Replace the Start Element’s complex formula with a simple, non-cross-object condition (e.g., "AccountId Is Not Null").
  • Add a Decision Element immediately after the Start Element.
  • In the Decision Element, create a new Formula Resource (type: Boolean) containing the original complex cross-object logic.
  • Set the Decision Element’s condition to: [Formula Resource] Equals {!$GlobalConstant.True}.
  • Route the "True" outcome to the existing flow logic; route the "Default" outcome to an End element.
  • Save and activate the new version.

Why this works: Logic inside the flow body (Decision Elements, Assignments, etc.) executes in System Mode, which bypasses field-level security restrictions. Only the Start Element’s entry criteria are subject to the running user’s permissions.

Best Practices for Prevention

Audit Scheduled Jobs Before License Changes

Before downgrading any user’s license to "Integration," "Minimum Access," or any restricted type—and before deactivating any user—always navigate to Setup > Scheduled Jobs and filter the "Submitted By" column for that user. Transfer ownership of any critical jobs before making the license change.

Use Dedicated Service Accounts for System Jobs

Avoid scheduling system-critical batch jobs under individual employee user accounts. Instead, create a dedicated service account (e.g., "NPSP Integration User" or "System Automation User") with a full System Administrator profile. Use this account exclusively for scheduling NPSP batch jobs, DLRS calculations, and other automated processes. This insulates your automation from employee turnover, license reclamation, and profile changes.

Minimize Cross-Object References in Flow Entry Criteria

As a general architectural practice, avoid placing complex cross-object formulas or field references in a Record-Triggered Flow’s Start Element. Reserve the Start Element for simple, single-object conditions and move complex evaluation logic to Decision Elements inside the flow body, where it benefits from System Mode execution.

Номер статьи базы знаний

005305532

 
Загрузка
Salesforce Help | Article