Salesforce Loyalty Management: Flow Failures When Invoking Data Processing Engine or Loyalty Program Processes

Work through the cause that matches the observed symptom.

Cause 1: Non-admin users cannot invoke DPE or Loyalty invocable actions from a flow

Screen Flows or autolaunched flows that invoke Data Processing Engine definitions or Loyalty standard invocable actions (such as runProgramProcess, runProgramProcessForTransactionJournal, or refreshDecisionTable) fail with unhandled faults for Standard Users and Experience Site / Community users. System Administrators succeed because "Modify All Data" bypasses the checks.

Important root-cause context: Object CRUD and Field-Level Security alone are not sufficient. The Flow engine resolves the Loyalty invocable action definition against the Loyalty managed-package publisher org before it ever reaches the Loyalty engine. For a non-admin user without the required Loyalty user permissions, the action definition returns null and the action never executes. The permission gate here is the Manage Loyalty user permission delivered by the Loyalty Management permission set and its associated permission set license.

Resolution steps:

1. Navigate to Setup > Permission Sets and open (or clone) the Loyalty Management permission set. Confirm the Loyalty Management permission set license is assigned to the user (Setup > Users > [user] > Permission Set License Assignments).
2. Under System Permissions, confirm the Manage Loyalty user permission is enabled. This is the gating permission required for non-admin users to invoke Loyalty standard invocable actions (runProgramProcess, runProgramProcessForTransactionJournal, etc.) from flows.
3. Under Object Settings, confirm Read and Create access on: DataProcessingEngineDefinition, DataProcessingEngineJob, BatchJobPart, LoyaltyProgram, LoyaltyProgramMember, LoyaltyMemberCurrency, TransactionJournal, and any custom objects referenced in DPE writeback nodes.
4. If the flow uses the refreshDecisionTable invocable action, confirm the permission set includes "Manage Decision Table" access and Read on DecisionTable and DecisionTableParameter.
5. If the DPE references Data Cloud segment objects (for example, MarketSegment, SegmentMembership), confirm Read access on those objects and the "Access Data Cloud Data" permission.
6. Navigate to Setup > Sharing Settings and confirm the OWD for DataProcessingEngineDefinition allows the required access (typically Public Read Only), or create a sharing rule granting Read to the relevant user group.
7. For Experience Site / Community users: Assign the same Loyalty Management permission set (and permission set license) via the Guest User profile or member Permission Set assignment, and confirm the site sharing rules expose the required Loyalty records.
8. Save, then have the affected user log out and log back in.
9. Re-run the flow as the non-admin user.

Verification: Execute the flow as a Standard User (and again as an Experience Site user, if applicable) with the updated permission set. Confirm the DPE or Loyalty invocable action completes without an unhandled fault and that the target records (for example, VoucherDefinition custom fields or member tier changes) are updated.

Cause 3: Duplicate or conflicting DPE definitions preventing activation or causing flow failures

DPE definitions cannot be edited while active and must be deactivated before editing. When both a managed-installed DPE (from packages such as Loyalty Management or Nonprofit Cloud Fundraising, indicated by a namespace prefix such as runtime_industries_loyalty__ResetQualifyingPoints) and an unmanaged DPE definition target the same writeback object, activation conflicts or runtime errors occur. Flows may invoke the wrong definition or fail because the system cannot resolve which definition to execute. A similar conflict occurs when a customer clones the OOTB managed Reset Qualifying Points definition and both remain active.

Resolution steps:

1. Navigate to Setup > Data Processing Engine.
2. Identify all DPE definitions targeting the same writeback object. Note which are managed (namespace prefix) and which are unmanaged.
3. Open each conflicting definition and click Deactivate. A DPE definition cannot be edited while active.
4. Deactivate the unmanaged duplicate if it was created inadvertently during troubleshooting or cloning.
5. If both definitions are required, rename the unmanaged definition to avoid naming collisions and update the flow's invocable action input to reference the correct DPE Definition Name explicitly.
6. Activate the correct DPE definition by opening it in the DPE Builder and selecting Activate.
7. Update the flow that invokes the DPE so that the DPE Definition Name input matches the activated definition's API name exactly.
8. Note: Managed DPE definitions with ManageableState = installed or released (for example, runtime_industries_loyalty__ResetQualifyingPoints) cannot be edited or deleted; only installedEditable or unmanaged definitions can be modified after deactivation.

Verification: Run the scheduled or screen flow that invokes the DPE. Confirm successful execution in Setup > Flows > Paused and Failed Flow Interviews (no new failures) and verify that target records are updated as expected.