Salesforce Experience Cloud CSV Import: Fix Portal Errors (2026)

Quick Answer

Salesforce Experience Cloud CSV imports fail for three reasons that don't appear in standard Data Import Wizard documentation: record type restrictions that apply to portal users but not internal users, sharing rule conflicts where imported records aren't visible to the community after import, and field-level security settings that silently strip data from portal-accessible fields.

Why it happens: Experience Cloud (formerly Community Cloud) adds a permission and visibility layer on top of standard Salesforce objects. A record that imports cleanly for an internal admin may be completely invisible or partially accessible to portal users due to OWD settings, sharing rules, and profile-level field permissions.

The fix: Validate your import CSV against the field permissions and record types assigned to your portal profiles before uploading — not just against the standard Salesforce field schema.

Root cause: Record type mismatches are among the most common Experience Cloud import failures. If your CSV assigns a record type that isn't enabled for the portal profile, records import for internal users but appear blank or inaccessible to community members.

---

Fast Fix (90 Seconds)

If your Experience Cloud import succeeded but portal users can't see the records:

1. Check record type — Navigate to Setup > Object Manager > [Object] > Record Types. Confirm the record type in your CSV is enabled for the portal user profile.
2. Check OWD — Go to Setup > Sharing Settings and verify the object's Organisation-Wide Default isn't set to Private in a way that blocks community access.
3. Check field visibility — Open the portal profile (Setup > Profiles > [Portal Profile]) and confirm the fields in your CSV are set to Visible, not Hidden.
4. Check sharing rules — Confirm a sharing rule exists that grants community users access to records owned by internal users.
5. If records are invisible after import — Run a quick SOQL query in Developer Console scoped to the portal user's perspective to confirm record visibility.

If the import itself is failing before records are created, continue below.

---

TL;DR: Experience Cloud imports require matching record types to portal profiles, OWD settings that allow community access, and field-level security on the portal profile. A valid internal Salesforce import can produce zero visible records in the community. Validate against your portal profile configuration — not just the standard object schema.

---

Your partner portal went live last month. You need to seed it with 4,000 partner account records from a spreadsheet migration. You run the import through the Data Import Wizard. It completes: 4,000 records imported, 0 errors. You log in as a test partner user and see nothing. The portal shows an empty list.

The import worked perfectly — for internal users. The records exist in Salesforce. They're simply invisible to anyone accessing via the portal because the sharing model wasn't configured before the import ran.

Salesforce import files for Experience Cloud contain business relationship data — partner names, contact details, deal pipeline information — that constitutes personal data under GDPR Article 4(1). Most cloud-based CSV validators upload the file to a remote server to validate it. For partner portal data, that upload creates a GDPR Article 5(1)(c) data minimization exposure and may trigger Article 28 Business Associate obligations if the validator processes on your behalf. SplitForge's Data Validator runs entirely in Web Worker threads in your browser — partner and customer data never reaches any external server. Confirm this with Chrome DevTools Network tab during validation: zero outbound requests.

Each error pattern in this guide was reproduced against a Salesforce org with an active Experience Cloud community and partner portal configuration, March 2026. For the complete CRM import failure taxonomy, see our CRM import failures complete guide. For Salesforce-specific import errors outside Experience Cloud, see Fix Salesforce Bad Value for Restricted Picklist and Salesforce Data Loader CSV Errors.

---

Why This Doesn't Show in the Error Log

This is the mental model that makes Experience Cloud imports hard. The import pipeline and the sharing pipeline are separate systems:

IMPORT PIPELINE (what the Data Import Wizard sees):
CSV → Field Validation → Record Created ✓ → Import log: 4,000 success

POST-IMPORT PIPELINE (what portal users experience):
Record exists in Salesforce
  ↓
Sharing layer check: OWD = Private → no sharing rule to portal → FAIL
  ↓
Record Type check: Internal_Account → not enabled for Partner Profile → FAIL
  ↓
FLS check: Partner_Tier__c = hidden on portal profile → silently blank
  ↓
Portal user view: zero records returned

Result: Import log says success. Portal shows empty list.
The error is real. It just doesn't appear where you looked for it.

This is why import success does not mean portal visibility success. Always verify as a portal user after any Experience Cloud import.

---

What Experience Cloud Import Errors Actually Look Like

❌ BROKEN — Experience Cloud import: records created but not visible to portal users

Import result: "4,000 records imported successfully. 0 errors."
Portal user sees: Empty list. Zero records.

Root cause diagnosis:
1. OWD on Account = Private → imported records owned by internal user, not shared
2. Record Type = "Internal_Account" → not enabled for Partner Community profile
3. Field "Partner_Tier__c" = not visible on Partner Profile → silently blank for portal

No import error is generated. The failure is post-import, at the sharing layer.

FIXED — pre-import checklist:
✓ Record type in CSV: "Partner_Account" (enabled for Partner Community profile)
✓ OWD on Account: Private + sharing rule grants Read/Write to partner users on owned records
✓ Field "Partner_Tier__c" set to Visible on Partner Community License profile
✓ Owner field in CSV: the Salesforce user who owns records community members should see

---

---

Table of Contents

• Why Experience Cloud Makes Import Harder
• Fix 1: Record Type Mismatches
• Fix 2: Sharing Rule Conflicts
• Fix 3: Field-Level Security Silent Drops
• Fix 4: Owner and Access Chain Failures
• Common Scenarios
• Additional Resources
• FAQ

---

Why Experience Cloud Makes Import Harder

Standard Salesforce imports validate against field types, required fields, and picklist values. Experience Cloud adds three additional validation layers that run after the record is created — not during import:

Layer 1 — Sharing model: OWD settings, sharing rules, and manual shares determine which records community users can see. Records imported without a sharing path to community users are invisible regardless of how correctly the CSV was formatted.

Layer 2 — Record type access: Portal user profiles have record type assignments. Records assigned to a record type not enabled for the portal profile are inaccessible to community users.

Layer 3 — Field-level security: Each field on each object has a visibility setting per profile. Fields that import correctly for internal users may be invisible or read-only for portal users.

None of these failures produce an import error. The Data Import Wizard reports success, and the records exist in Salesforce — they're just inaccessible to the community.

PLATFORM SPECIFICATION SOURCE
Platform: Salesforce Experience Cloud (formerly Community Cloud)
Source: Salesforce Help — Sharing in Experience Cloud Sites
URL: https://help.salesforce.com/s/articleView?id=sf.networks_sharing_overview.htm
Verified: March 2026
Next re-verify: June 2026

Experience Cloud sharing behavior and record type assignment rules reflect
Spring '26 release behavior. Salesforce updates these with each seasonal
release — verify against current documentation before large portal data migrations.
OWD external access settings may differ from internal settings; verify both.

---

Fix 1: Record Type Mismatches

Every record in Salesforce belongs to a record type. Experience Cloud portal profiles have explicit record type assignments — if a portal user's profile doesn't include a specific record type, records of that type are invisible to them.

❌ BROKEN — Record type in import CSV not enabled for portal profile:

CSV field: RecordTypeId = "012XX000000AAAA" (Internal_Account record type)
Portal profile: Only has access to "Partner_Account" record type

Result: Import succeeds. Internal users see the record correctly.
Portal users cannot see or access the record at all.

FIXED — correct record type for portal visibility:
Step 1: Setup > Object Manager > Account > Record Types
Step 2: Note the Record Type ID for "Partner_Account"
Step 3: Update CSV RecordTypeId column to the Partner_Account ID
         OR use the Developer Name: RecordTypeName = "Partner_Account"
Step 4: Confirm Partner_Account is enabled for the portal profile:
         Setup > Profiles > [Partner Community Profile] > Record Types

Getting record type IDs: In Salesforce Setup, navigate to Object Manager > [Object] > Record Types. The ID appears in the URL when you open a record type. Alternatively, use the Record Type Developer Name in your CSV (Salesforce resolves names to IDs during import).

---

Fix 2: Sharing Rule Conflicts

Salesforce's Organisation-Wide Default (OWD) for an object determines the baseline access level. When OWD is set to Private, users can only see records they own or that have been explicitly shared with them.

For Experience Cloud, this creates a specific problem: records imported by an internal admin are owned by that admin. Without a sharing rule that grants portal users access to those records, the records are invisible in the community.

❌ BROKEN — Import creates records owned by internal admin, no sharing to portal:

OWD for Account: Private
Import runs as: [email protected] (internal admin user)
Records created: Owner = [email protected]
Portal user: [email protected]

Result: [email protected] can see all imported records.
[email protected] sees nothing.
No error produced anywhere.

FIXED — sharing rule that exposes records to portal users:

Option A: Change OWD to Public Read Only
  Setup > Sharing Settings > Account > Default External Access = Public Read Only
  All portal users can now see all Account records.

Option B: Create a sharing rule (more controlled)
  Setup > Sharing Settings > Account > New Sharing Rule
  Based on: Owner membership in [Internal Users] public group
  Share with: [Partner Community] user group
  Access: Read/Write (or Read Only depending on your use case)

OWD has two settings in Experience Cloud orgs: Internal Access and External Access. External Access applies to community users. Setting External Access to Public Read Only while keeping Internal Access at Private gives community users visibility without granting internal changes.

---

Fix 3: Field-Level Security Silent Drops

Field-level security (FLS) is set per field, per profile. When a field is set to Hidden for the portal profile, it doesn't produce an error — it simply doesn't appear when a portal user views the record. Fields that imported correctly are invisible to community members.

❌ BROKEN — Field imported successfully but hidden for portal profile:

CSV field: Partner_Tier__c = "Gold"
Internal user sees: Partner_Tier__c = "Gold" ✓
Portal user sees: Partner_Tier__c = [blank] or [field not shown]

No error. No warning. The data exists in Salesforce but is not exposed to portal.

FIXED — set field visibility on portal profile:
Setup > Profiles > [Partner Community Login User] > Field-Level Security
  OR
Setup > Object Manager > Account > Fields & Relationships > [Field] > Set Field-Level Security
  → Find Partner Community Login User profile row
  → Set: Visible = ✓, Read-Only = [per your needs]

When building an Experience Cloud import, audit field-level security for every field in your CSV against the portal profile before importing. Use this SOQL query to prove what the portal profile can actually see — run it in Developer Console as the portal user context:

SOQL PROOF — confirms portal visibility before and after import:

-- Run as internal admin (sysadmin context):
SELECT Id, Name, Partner_Tier__c FROM Account LIMIT 5
→ Returns: 5 records, Partner_Tier__c populated

-- Run as portal user (use executeSOQL in Developer Console with portal user context):
SELECT Id, Name, Partner_Tier__c FROM Account LIMIT 5
→ Returns: 0 records

The 0-record result confirms the sharing layer failure.
No amount of CSV formatting fixes this — it's a sharing configuration issue.

FIXED — after adding sharing rule:
-- Run as portal user:
SELECT Id, Name, Partner_Tier__c FROM Account LIMIT 5
→ Returns: 5 records, Partner_Tier__c = null (FLS hidden for portal profile)

Still null on Partner_Tier__c → now confirms FLS issue, not sharing issue.
Fix FLS on portal profile → rerun query → field populated.

---

Fix 4: Owner and Access Chain Failures

Experience Cloud has specific rules about how record ownership flows through relationship chains. A Contact linked to an Account must have the Account accessible to portal users, or the Contact may be inaccessible even if the Contact record itself would otherwise be visible.

❌ BROKEN — Contact import fails with cross-reference access error:

Import: Contact records with AccountId = 001XX000003AAAA
         (Account owned by internal user, not shared with portal)
Portal OWD on Account: Private

Error (in Data Loader error.csv):
Row 1: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY
       AccountId: 001XX000003AAAA
       "Contact cannot be linked to an Account you don't have access to"

Row 2: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY
       AccountId: 001XX000003BBBB
       "Contact cannot be linked to an Account you don't have access to"

All 4,000 Contact rows fail with this error.
Zero contacts imported. Zero records created.
This IS a hard error (unlike the FLS silent drop) — rows are rejected.

FIXED:
Create sharing rule: Account OWD = Private + sharing rule grants
Partner Community Users Read access to Accounts owned by [Internal Users] public group

After sharing rule is active: reimport → all 4,000 contacts import successfully.

---

Common Scenarios

Seeding a new partner portal with initial data

The safest sequence for initial portal seeding: (1) configure sharing rules and OWD before importing, (2) create a test portal user, (3) import a 10-row sample, (4) log in as the test portal user and verify record visibility, (5) run the full import. This catches sharing misconfigurations before they affect the full dataset.

Migrating from one Experience Cloud org to another

When migrating between orgs, record type IDs do not transfer. A record type named "Partner_Account" in the source org has a different 18-character ID in the destination org. Always use Record Type Developer Names in your CSV rather than IDs when migrating across orgs — Salesforce resolves names to the correct destination IDs during import.

Partner contact imports with relationship to account

When importing Contacts that belong to partner Accounts, import the Account records first and establish sharing rules before importing Contacts. Contacts inherit Account sharing in many configurations — getting Account visibility right first prevents Contact access problems downstream.

---

Additional Resources

Official Salesforce Documentation:

• Salesforce Experience Cloud — Sharing in Communities — OWD, sharing rules, and record visibility for Experience Cloud
• Salesforce — Data Import Wizard — Standard import guide with field mapping
• Salesforce — Field-Level Security — Profile-based field visibility configuration

Technical Reference:

• Salesforce — Record Type Assignments — Assigning record types to profiles

Tested: Salesforce Experience Cloud (Partner Community configuration), Data Import Wizard and Data Loader, March 2026. Each error pattern reproduced against a sandbox org with active partner portal and custom sharing rules.

PLATFORM SPECIFICATION SOURCE
Platform: Salesforce Experience Cloud (formerly Community Cloud)
Source: Salesforce Help — Experience Cloud Sharing and Data Import
URL: https://help.salesforce.com/s/articleView?id=sf.networks_sharing_overview.htm
Verified: March 2026
Next re-verify: June 2026

Experience Cloud sharing behavior and record type assignment rules
reflect Spring '26 release behavior. Salesforce updates these with
each seasonal release — verify against current documentation before
large portal data migrations.

---

FAQ