Partner portal migration results in missing user roles and access permissions

We’ve migrated our partner user data to Adobe Experience Cloud’s partner portal, but user roles and access permissions weren’t properly transferred. About 300 partner users now have default access levels instead of their configured roles from our legacy portal.

The bulk user import completed without errors, but when partners log in, they’re missing critical permissions:


User Import Summary: 312 users created
WARNING: Role 'Partner_Admin' not found - assigned default 'Partner_User'
WARNING: Custom permission set 'Deal_Registration_Access' not mapped
ERROR: Profile 'Gold_Partner_Profile' does not exist in target org

Our legacy system had custom role hierarchies (Gold/Silver/Bronze partners) with different permission levels for deal registration, opportunity access, and case submission. We need guidance on proper role mapping configuration, how to validate permission sets during migration, and whether we need to create custom roles in AEC before the import. Partner access disruption is affecting our channel sales operations.

Let me provide a complete solution addressing all three focus areas:

Role Mapping Configuration:

First, understand that AEC partner portals use a different security model than your legacy system. You need to configure these components in order:

  1. Partner Community Setup:

    • Navigate to Setup > Communities > Partner Community
    • Enable Partner Community if not already active
    • Create Partner Community profiles for each tier:
      • Gold_Partner_Profile
      • Silver_Partner_Profile
      • Bronze_Partner_Profile
  2. Role Hierarchy Configuration: Partner roles must be structured under partner account roles. Example hierarchy:

    
    Partner Account: Acme Corp
    ├── Acme_Partner_Manager (account-level role)
    │   ├── Acme_Gold_Partner_User
    │   └── Acme_Silver_Partner_User
    
  3. Legacy to AEC Role Mapping: Create a mapping document:

    • Legacy: Partner_Admin → AEC: Partner_Community_Manager (profile) + Partner_Account_Manager (role)
    • Legacy: Gold_Partner → AEC: Gold_Partner_Profile + Gold_Partner_User (role)
    • Legacy: Silver_Partner → AEC: Silver_Partner_Profile + Silver_Partner_User (role)
    • Legacy: Bronze_Partner → AEC: Bronze_Partner_Profile + Bronze_Partner_User (role)

Permission Set Validation:

Create permission sets for functional capabilities:

  1. Deal_Registration_Access Permission Set:

    • Object: Opportunity (Create, Read, Edit)
    • Object: Deal_Registration__c (All permissions)
    • Field: Opportunity.Partner_Discount__c (Visible, Editable)
    • Tab: Deal Registration (Visible)
  2. Case_Submission_Access Permission Set:

    • Object: Case (Create, Read)
    • Object: Case Comment (Create, Read)
    • Field: Case.Partner_Priority__c (Visible, Editable)
  3. Opportunity_View_Access Permission Set:

    • Object: Opportunity (Read only)
    • Field: Opportunity.Amount (Visible)
    • Report Folder: Partner Opportunities (Access)

Validation Process Before Migration:


1. Export partner user list with legacy roles
2. Create role mapping table (legacy role → AEC profile + role)
3. Validate each AEC profile exists: Setup > Profiles
4. Validate each permission set exists: Setup > Permission Sets
5. Test role hierarchy: Assign test user and verify record visibility
6. Test permission sets: Login as test user and verify object access

Custom Role Creation:

For each partner tier, create roles with proper naming convention:

  1. Gold Partner Role Creation:

    • Setup > Users > Roles > New Role
    • Label: “Gold Partner User - [Account Name]”
    • Report To: Partner Account Manager role
    • Contact Access: Controlled by Parent
    • Opportunity Access: Controlled by Parent
  2. Permission Set Assignment Strategy:

    • Gold Partners: All three permission sets (Deal Registration + Case Submission + Opportunity View)
    • Silver Partners: Case Submission + Opportunity View
    • Bronze Partners: Case Submission only

Import File Structure:

Your user import CSV must include these columns:


Username, Email, Profile, Role, PermissionSetGroup, AccountId
partner1@acme.com, partner1@acme.com, Gold_Partner_Profile, Gold_Partner_User_Acme, Gold_Partner_Permissions, 001xx000003DGHI

Post-Migration Validation Steps:

  1. Role Assignment Verification:

    • Run report: Users with Role = “Partner_User” (default)
    • These users need role reassignment
    • Use Data Loader to bulk update Role field
  2. Permission Set Validation:

    • Query: SELECT Id, Name, (SELECT AssigneeId FROM PermissionSetAssignments) FROM PermissionSet
    • Verify each partner user has appropriate permission set assignments
    • Missing assignments can be bulk-added via Data Loader
  3. Access Testing:

    • Login as partner user from each tier
    • Verify object access matches tier permissions
    • Test record visibility through role hierarchy
    • Confirm tab visibility matches permission sets

Correcting Your Current Migration:

Since your 312 users are already imported with default access:

  1. Create all required profiles and permission sets (as detailed above)
  2. Create role hierarchy for each partner account
  3. Export current user list with their legacy role mappings
  4. Use Data Loader to update:
    • User.ProfileId (map to correct partner profile)
    • User.UserRoleId (assign correct role in hierarchy)
  5. Bulk assign permission sets using Setup > Permission Sets > Manage Assignments
  6. Validate access for 10-15 test users across different tiers
  7. Communicate access restoration to partner users

Best Practices:

  • Always create security components (profiles, roles, permission sets) BEFORE user import
  • Use permission set groups to bundle related permissions by tier
  • Test role hierarchy with shared records to verify visibility
  • Document role mapping for future partner onboarding
  • Set up automated permission set assignment rules for new partners

This approach will restore proper access for your 312 partner users and establish a scalable security model for future partner onboarding.


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

The user import tool doesn’t automatically create roles or permission sets - they must exist in AEC before import. You need to pre-configure your partner role hierarchy in Setup > Users > Roles and create corresponding permission sets. Then your import CSV should reference these by exact API name.

For partner portals specifically, you’ll need to set up Partner Community profiles first, not standard user profiles. Go to Setup > Communities > Partner Community and configure your partner profiles there. Each profile can have different object and field permissions. Your Gold/Silver/Bronze tiers should map to separate Partner Community profiles.

Also check if your permission sets are properly associated with the profiles. Even if you create custom roles, the permission sets need explicit assignment. We had a similar issue where users had correct roles but missing permissions because the permission set assignments weren’t included in the import file. You need a separate column in your CSV for permission set assignments.

So we need to create the Partner Community profiles first, then map our legacy roles to those profiles in the import file? What about the custom permissions like deal registration access - do those need to be permission sets?

“Tested this on AEC Partner Community migration with Gold/Silver/Bronze tier profiles — configuring Partner Community profiles in Setup before role hierarchy eliminated missing permission issues completely.”

Yes, custom permissions should be permission sets. Create permission sets for each functional area (Deal Registration, Case Submission, Opportunity Access) and assign them based on partner tier. This gives you flexibility - a Gold partner might get all three permission sets, while Bronze gets only Case Submission. Use permission set groups to bundle them by tier for easier management.

Don’t forget to validate the role hierarchy after creation. Partner roles need to be under a specific partner account’s role in the hierarchy. If your role hierarchy isn’t structured correctly, partners won’t see records they should have access to through role-based sharing. Test with a few users before doing the full permission assignment.