Partner onboarding flow fails on account creation step with access-error

CRM Salesforce
, , , , , , , ,
1

We’re hitting a wall with our automated partner onboarding flow in Spring '25. The flow handles everything from initial registration through account setup, but it consistently fails at the account creation step with an access error.

The flow runs in system context, and we’ve verified the flow has proper object permissions. Portal user profile permissions look correct for Account object, but something’s blocking the account creation. We suspect it might be related to object sharing settings since the error only appears when creating accounts for portal users.

Here’s the error we’re seeing:


INSUFFICIENT_ACCESS: insufficient access rights on object id
at Account.Create element in Partner_Onboarding_Flow

The flow worked perfectly in our sandbox, but production is a different story. Any insights on what sharing configuration we might be missing?

system 2

Here’s the complete solution based on your setup:

Root Cause: The Private OWD on Account object combined with portal user restrictions is blocking account creation. Portal users operate under stricter sharing rules than internal users, and your flow needs to account for this.

Solution - Three-Part Fix:

  1. Object Sharing Settings: Create a criteria-based sharing rule for partner accounts:
  • Navigate to Setup → Security → Sharing Settings → Account Sharing Rules
  • Create rule: Share accounts where RecordType = ‘Partner’ OR Type = ‘Partner’
  • Grant ‘Read/Write’ access to your Partner Portal Users group
  • This ensures newly created accounts are immediately accessible
  1. Portal User Profile Permissions: Verify these permissions on the Partner Portal User profile:

Account Object: Read, Create, Edit (confirmed you have this)
Account Sharing: "View All" NOT needed if sharing rule covers it
System Permissions: "API Enabled" if flow calls external services
  1. Flow Configuration Adjustments: Update your Partner_Onboarding_Flow:
  • Set the Account Owner field to a user who’s already accessible to portal users (typically the partner account executive or a queue)
  • Add a field update immediately after account creation to set a flag (like Partner_Account__c = true) that your sharing rule can use
  • Consider adding a “Create Records” element after account creation to explicitly create AccountShare records if needed:

AccountShare share = new AccountShare();
share.AccountId = {!newAccountId};
share.UserOrGroupId = {!portalUserId};
share.AccountAccessLevel = 'Edit';

Why Sandbox Worked: Your sandbox has Public Read/Write OWD on Account, which bypasses all sharing restrictions. Production’s Private OWD enforces strict sharing, exposing this gap.

Testing Approach:

  • First, implement the criteria-based sharing rule in production
  • Test with a single partner registration
  • Monitor the debug logs for any remaining access errors
  • If sharing rule doesn’t fire immediately, add the explicit AccountShare creation in the flow

Additional Validation: Add error handling in your flow to capture and log specific access errors. This helps identify if there are other permission gaps beyond account creation (like related objects - Contacts, Opportunities, etc.).

The sharing rule approach is cleaner than explicit share creation because it’s declarative and automatically covers future scenarios. Only resort to programmatic sharing if the criteria-based rule doesn’t meet your needs.

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 scenario. The issue is usually that portal user accounts need special handling in flows. Check if your flow is set to run in ‘System Mode Without Sharing’ - that’s often the culprit. Portal users have restricted access by default, and even though the flow runs in system context, it might still respect those restrictions depending on the execution mode.

5

Quick thought - are you using a record-triggered flow or screen flow? If it’s screen flow, the running user context matters. Also, verify that the Account object’s organization-wide defaults aren’t set to Private. Portal users need explicit sharing rules or the parent account needs to be accessible. The fact that it works in sandbox suggests your production org might have different sharing model settings.

6

It’s an autolaunched flow triggered from a custom Lightning component. The OWD for Account is Private in production (Public Read/Write in sandbox - that explains the difference!). We do have sharing rules set up for partner accounts, but they might not be covering this scenario. The portal user profile has Create permission on Account, but I’m wondering if the sharing rules need to explicitly grant access to accounts created by the flow itself.

7

The Private OWD is definitely your issue. When the flow creates an account for a portal user, that account needs to be immediately accessible to that portal user. With Private OWD, you need either: 1) A sharing rule that grants access based on criteria (like Account Type = Partner), or 2) Manual share records created by the flow itself. I’d recommend option 1 - create a criteria-based sharing rule for partner accounts. Make sure the criteria matches what your flow sets on the new accounts.

8

Also worth checking: does your portal user profile have ‘View All’ or ‘Modify All’ on the Account object? Those permissions bypass sharing rules entirely. If not, and you’re using Private OWD, the portal user literally can’t see the account being created, which causes the flow to fail. Another thing - verify that the account owner being set by the flow is someone the portal user can access through the role hierarchy or sharing rules.