Loyalty points not updating after flow execution for tiered rewards program

CRM Salesforce
, , , , , , , ,
1

We’ve implemented an automated flow to update loyalty points for our tiered rewards program in Summer '25. The flow executes successfully without errors, but the Loyalty_Points__c field on the Account object remains unchanged after completion.

The flow triggers when a purchase record is created and should calculate points based on the customer tier (Bronze/Silver/Gold multipliers). The debug logs show the flow reaching the Update Records element with correct variable values, but the field value doesn’t persist to the database.

I’ve verified the flow variable mapping looks correct - we’re capturing the Account ID and calculating the new point total before the update step. The flow runs under the system context, and I can manually update the field through the UI without issues. Has anyone encountered similar behavior where Update Records elements complete successfully but field values don’t actually change?

system 2

Check your assignment logic before the Update Records element. In Flow Builder, open your Assignment element and verify you’re setting the field value on the correct record variable. The pattern should be: {!AccountRecord.Loyalty_Points__c} = {!CalculatedPoints}.

Based on your description about field-level security, variable mapping, and the Update Records element, here’s what’s likely happening:

Field-Level Security Issue: Summer '25 enforced stricter FLS checks. Go to Setup > Security > Field Accessibility > Account > Loyalty_Points__c and verify the ‘Automated Process’ user profile has Edit access. This is critical even for system-context flows.

Variable Mapping Verification: Your flow should follow this sequence:

  1. Get Records: Query the Account using the Purchase’s Account__c lookup field
  2. Assignment: Create a new variable {!CalculatedPoints} = {!AccountRecord.Loyalty_Points__c} + ({!PurchaseAmount} * {!TierMultiplier})
  3. Assignment: Set {!AccountRecord.Loyalty_Points__c} = {!CalculatedPoints}
  4. Update Records: Update {!AccountRecord}

The key is that you must assign the new value BACK to the record variable’s field before the Update Records element. Don’t just calculate it in a separate variable.

Update Records Element Configuration: Open your Update Records element and ensure:

  • How to Find Records: ‘Use the IDs and all field values from a record or record collection’
  • Record Collection or Record: {!AccountRecord}
  • Do NOT use ‘Specify conditions’ - this creates a fresh query and ignores your variable changes

Common mistake: Using ‘Use separate resources’ mode and trying to specify Account ID + field values separately. This bypasses your variable assignments entirely.

Debug Strategy: Add a Screen element right before your Update Records step (temporary, for testing). Display {!AccountRecord.Id} and {!AccountRecord.Loyalty_Points__c}. Run the flow and verify the screen shows the updated point value. If it does, but the database doesn’t reflect it, you have a validation rule or trigger rolling back the change. If the screen shows the old value, your Assignment element isn’t working correctly.

Test with debug logs enabled at FINEST level for Workflow and Validation. Look for the actual DML statement in the logs - it should show the new Loyalty_Points__c value being sent to the database. If you see the old value in the DML, the Assignment failed. If you see the new value but it doesn’t persist, look for VALIDATION_FORMULA or FIELD_CUSTOM_VALIDATION_EXCEPTION entries immediately after.

This combination of FLS enforcement changes, proper variable assignment patterns, and correct Update Records configuration should resolve your issue. The field-level security angle is particularly important in Summer '25 - verify that specific permission first.

This draft is based on general Salesforce knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Check field-level security settings first. Even though the flow runs in system context, Summer '25 introduced stricter FLS enforcement for certain custom fields. Navigate to Setup > Object Manager > Account > Fields > Loyalty_Points__c and verify the field is editable for the profiles associated with your automation user.

4

I’ve seen this exact issue when the Update Records element uses the wrong record collection variable. In your flow’s Update Records element, make sure you’re updating using the Account ID you captured initially, not trying to update a collection. Also verify that your assignment step before the update is actually storing the calculated points value to the correct field reference. Sometimes the variable mapping can look right visually but reference the wrong API name - double-check that Loyalty_Points__c matches exactly including the __c suffix and any namespace prefix if you’re in a managed package environment.

5

Are you using a Record-Triggered Flow or an Autolaunched Flow? If it’s record-triggered on the Purchase object, the timing might matter. The Account update could be happening before the Purchase record transaction commits. Try adding a Scheduled Path that runs 1 minute after the trigger to see if that resolves it. This gives the system time to complete the initial transaction.

6

Had the same problem last month. Check if there’s a validation rule or trigger on the Account object that’s silently failing the update. Even though your flow shows success, a validation rule firing after your flow’s update can roll back the change without throwing an error visible in the flow debug. Go to Setup > Object Manager > Account > Validation Rules and temporarily deactivate them one by one to isolate the issue.

ashleyadmin 7

Tested this on Summer '25 org — granting Field-Level Security read/write access to Automated Process profile on Loyalty_Points__c resolved the silent update failure in our tiered rewards Flow.

8

Another thing to verify - in your Update Records element configuration, make sure you selected ‘Use the IDs and all field values from a record or record collection’ rather than ‘Use separate resources and literal values’. The first option is more reliable for field updates. Also, confirm your flow version is activated. I’ve debugged flows before where I was testing an inactive version while the active version had old logic.