We deployed our loyalty management system to the cloud during Spring '24 upgrade and now member points aren’t updating correctly. The Flow Builder automation that handles point accrual runs without errors, but the LoyaltyProgramMember records show stale point values.
The flow executes successfully in debug mode, but checking field-level security and object permissions hasn’t revealed any issues. Points worked fine in our on-premise setup before migration. Has anyone encountered similar field update problems after cloud deployment with Flow Builder? I’m wondering if there’s something specific about how flows handle field updates in the cloud environment.
Looking at your code, I see the root cause. Your Flow is using assignment to update the TotalPoints field, but you need to refresh the record context after the Get Records element. In cloud deployments, record locking behaves differently.
Here’s the corrected approach addressing all three critical areas:
Flow Builder Debugging Fix:
Add a Get Records element immediately before your Update to refresh the member record. This ensures you’re working with the latest field values and proper record lock.
Field-Level Security Check:
// Verify FLS in your flow's running user context
Schema.DescribeFieldResult fieldDescribe =
LoyaltyProgramMember.TotalPoints.getDescribe();
if(!fieldDescribe.isUpdateable()) {
// Flow will fail silently without proper FLS
}
Object Permissions Review:
Navigate to Setup → Loyalty Program Member → Field-Level Security. Ensure your Flow’s running user profile has Edit access to TotalPoints. Cloud deployments reset some profile permissions during migration.
The key issue is that Spring '24’s cloud platform caches field values more aggressively. Your assignment operation updates the in-memory variable but doesn’t refresh from the database before the Update Records element executes. This causes a race condition where stale values overwrite your calculated points.
Implementation Steps:
Add a second Get Records element right before Update Records
Use the refreshed record for your assignment
Verify all profiles in Setup → Profiles → Object Settings → Loyalty Program Member
Check that System Administrator and your custom profiles have Edit on TotalPoints
Review any field dependencies that might create circular update patterns
After implementing this, test with a single member first, then gradually increase volume. The cloud environment’s different locking mechanism requires this refresh pattern for reliable field updates in Flows. This pattern is now a best practice for all cloud-deployed Flow Builder automations that update calculated fields.
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.
I’ve seen this exact scenario. Check if your Flow is running in System Mode versus User Mode. After cloud deployments, the execution context can change. Also verify that the LoyaltyProgramMember object has proper sharing rules configured - cloud environments enforce sharing more strictly than some on-premise setups.
Are you using any before/after triggers on LoyaltyProgramMember? I had a similar issue where a trigger was reverting the point values because it was referencing cached data. The cloud deployment changed our trigger execution order. Try temporarily disabling custom triggers to isolate whether it’s a Flow issue or trigger interference. Also check your Process Builder processes - sometimes those conflict with Flows in unexpected ways post-migration.
Confirmed this resolves the stale record issue — adding a Get Records element before the Update Record element in Flow Builder fixed our loyalty points sync after the Spring '24 deployment.
Good catches both. I verified the Flow is running in System Mode. We do have a before update trigger that recalculates tier status based on points. I’ll test with it disabled.
Another thing to check - Spring '24 introduced stricter validation rules for formula fields. If TotalPoints is referenced in any rollup summaries or formulas, those might be blocking the update silently. Check your debug logs for FIELD_CUSTOM_VALIDATION_EXCEPTION entries. The cloud platform enforces field dependencies more rigorously than legacy systems, so circular references that were tolerated before might now cause silent failures in your Flow’s Update Records element.
I experienced this after our Spring '24 migration. The issue was that our Flow was updating records in a bulkified operation, but the cloud environment’s governor limits were causing partial failures. Even though the Flow showed success, only the first batch of records actually updated. Check if you’re processing multiple members simultaneously - you might need to implement proper bulkification patterns or split your Flow into smaller chunks.