Automated approval flow fails for opportunity records due to insufficient permissions

CRM Salesforce
, , , , , , , ,
1

We’ve implemented an automated approval flow in Flow Builder that should trigger when opportunity amount exceeds $50K. The flow worked perfectly in sandbox, but in production it’s failing for most sales reps with a generic “Insufficient Privileges” error.

The flow is supposed to:

  1. Check opportunity amount
  2. Lock the record
  3. Submit for approval to the sales manager
  4. Update approval status field

Error occurs at step 3:


Error: INSUFFICIENT_ACCESS_OR_READONLY
Failed to submit for approval
User lacks required permissions on Opportunity object

I’ve verified the sales reps have Edit access on Opportunities through their profile, and they can manually submit records for approval without issues. The problem only happens when the Flow Builder automation triggers. Our permission sets control field-level security for several custom fields on the Opportunity object, including the approval status field. What permission configuration am I missing that allows manual submission but blocks automated flow submission?

system 2

Let me clarify the complete picture here because there are multiple permission layers at play.

Permission Set Object-Level Access: Your sales reps need Read and Edit on the Opportunity object - you have this covered. However, for automated approval flows, you also need the “Submit Records for Approval” system permission in the permission set. This is separate from object CRUD and is specifically required when Flow Builder or other automation submits records. Manual submission by users doesn’t require this permission, which is why your reps can submit manually but the flow fails.

Field-Level Security: The approval status field issue is critical. Your flow is trying to update this field, but if FLS restricts edit access for sales reps, the flow will fail even in system context when it’s updating user-accessible records. You have three options:

  1. Grant FLS edit access on the approval status field to the permission set (simplest but may violate security requirements)
  2. Split the update into two steps: flow updates a staging field (users have edit access), then a trigger in system context updates the restricted field
  3. Configure the flow to run in system mode without sharing, but this bypasses your sharing rules entirely

Flow Builder Automation: The flow execution mode matters. Check your flow settings:


Setup → Flows → [Your Flow] → Open
In Flow Properties, verify:
- Run As: System (recommended for approval automation)
- Sharing: With Sharing (maintains record access rules)

For your specific scenario, implement these changes:

  1. Add system permission to your permission set:

Setup → Permission Sets → Sales_Rep_Permissions
→ System Permissions
→ Enable "Submit Records for Approval"
  1. For the field-level security conflict, I recommend the staging field approach:
  • Create a new field: Approval_Status_Staging__c (grant FLS edit to sales reps)
  • Modify your flow to update this staging field instead
  • Create an after-update trigger on Opportunity:
trigger OpportunityApprovalSync on Opportunity (after update) {
    List<Opportunity> oppsToUpdate = new List<Opportunity>();
    for (Opportunity opp : Trigger.new) {
        if (opp.Approval_Status_Staging__c != Trigger.oldMap.get(opp.Id).Approval_Status_Staging__c) {
            Opportunity oppUpdate = new Opportunity(Id = opp.Id);
            oppUpdate.Approval_Status__c = opp.Approval_Status_Staging__c;
            oppsToUpdate.add(oppUpdate);
        }
    }
    if (!oppsToUpdate.isEmpty()) {
        update oppsToUpdate; // Runs in system context
    }
}
  1. Keep your flow in “Run As System” mode but maintain “With Sharing” to respect record-level access

This approach maintains your security model (users can’t directly edit the approval status field) while allowing the automated flow to function properly. The trigger runs in system context and can update restricted fields regardless of user permissions.

After implementing these changes, test in sandbox first. The “Submit Records for Approval” system permission is the most commonly missed piece in this scenario.

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

I’ve seen this exact issue before. The problem is that Flow Builder runs in system context by default, but when it tries to submit records for approval, it switches to user context and checks the running user’s permissions. Even though your sales reps can manually submit, the flow needs explicit permission to the approval process itself. Check if your permission sets grant “Modify All Data” or at least “Modify All” on Opportunities - that’s usually what’s missing.

4

Also verify the field-level security on your custom approval status field. If the flow is trying to update that field and the user doesn’t have edit access through their permission set, you’ll get this error. The flow might need to run in system mode without sharing for the field update portion. You can set this in the flow properties under “How should the flow handle record-level access?”

5

Thanks for the suggestions. I checked and the sales reps definitely don’t have Modify All Data (we restrict that to admins only). The approval status field has read-only access for sales reps through FLS. I’m hesitant to change the flow to run in system mode without sharing because we have complex sharing rules. Is there a way to grant just enough permission for the approval submission without opening up Modify All?

nancy_guru 6

Tested this on a Spring '24 org where adding “Submit Records for Approval” to the automation user’s permission set immediately resolved our Flow Builder approval submission failures.

7

You don’t need Modify All Data for this. What you need is to ensure the permission set includes object-level “Read” and “Edit” on Opportunity (which you have), plus the “Submit for Approval” system permission. That’s a separate permission from object CRUD. Go to Setup → Permission Sets → [Your Permission Set] → System Permissions and enable “Submit Records for Approval”. This is often overlooked because manual submission doesn’t require it - only automated processes do.

8

The field-level security issue is real though. If your flow updates the approval status field and users don’t have edit access, you need to either grant FLS edit permission on that field OR modify your flow to use a separate field that users CAN edit, then have a process builder or trigger update the restricted field in system context. We went with the second approach to maintain our security model. Created a staging field with user edit access that the flow updates, then a trigger copies it to the actual approval field.