User roles are not just labels. They are the mechanism that controls what a person can see, access, and do on your WordPress site. When you run more than one WordPress site and users need to exist on all of them, the role question becomes surprisingly complex. A role that means one thing on Site A may not exist at all on Site B. A permission level that makes sense for a store customer has entirely different implications for a course student. And the way membership plugins, LMS platforms, and community tools define their own custom roles means that even two WordPress sites running the same set of plugins can have meaningfully different role structures.
The common failure mode is this: someone builds a user sync between their two WordPress sites, tests it with an admin account, confirms that users are appearing on both sites, and declares it working. Two weeks later a customer emails to say they purchased a course but cannot access it. The user account was synced correctly. The role was not. The customer arrived on the LMS site as a Subscriber with no course access, rather than as a Student with the permissions their purchase entitled them to.
Role mapping is the feature that prevents this failure. It is the configuration layer that tells your sync system not just to copy a user from Site A to Site B, but to assign that user the correct role on Site B based on their role on Site A. This guide explains how role mapping works, when it matters most, and how to configure it correctly for the most common WordPress multi-site architectures.
Why roles cannot simply be copied between WordPress sites
WordPress has a set of default roles: Subscriber, Contributor, Author, Editor, and Administrator. If both of your sites use only these default roles and have exactly the same permission structure, copying the role field from one user record to another would work correctly. In practice, this situation is extremely rare for any multi-site operator with meaningful user management needs.
The reality is that most WordPress sites running memberships, LMS platforms, e-commerce, or community features use custom roles defined by their plugins. WooCommerce adds a Customer role. LearnDash adds a Student role and sometimes program-specific roles. MemberPress, Restrict Content Pro, and other membership plugins add their own role structures. bbPress creates Participant, Moderator, and Keymaster roles for community forums. Each of these roles exists only on sites where the corresponding plugin is active.
If a sync process copies the role “student” from your LearnDash site to your WooCommerce store, WordPress on the store side will reject the role assignment or silently fall back to the default Subscriber role because “student” is not a registered role on that installation. The user gets created with incorrect or default permissions. They may be able to browse but not purchase, or be treated as a first-time visitor even though they are a known customer. The sync appeared to work. The permissions are wrong.
Beyond the technical incompatibility, there is also the intentional mismatch case. Sometimes you do not want to copy the role at all. A user who is a Customer on your WooCommerce store should not necessarily become a Customer on your LearnDash site. “Customer” may not even be a valid role on the LMS. What you actually want is for the purchase event or the membership status on the store to trigger a specific role assignment on the LMS, and that assignment should be configured by you, not inferred from whatever role the user happened to have on the source site.
This is the core insight behind role mapping: the role a user has on Site A and the role they should have on Site B are related, but they are not the same thing and they should not be treated as the same thing. A proper WordPress user sync plugin with role mapping between connected sites lets you define that relationship explicitly, so every user lands with exactly the right permissions regardless of how the role names differ between your installations.
How role mapping works
Role mapping is a configuration table that you define for each site connection. It answers a specific question for each role on Site A: when a user with this role is synced to Site B, what role should they receive there? The mapping is evaluated every time a user sync event is processed, whether that is a new registration, a profile update, or a role change event.
The mapping is evaluated at sync time, not at login time. This means the role assignment happens the moment the user event is processed, whether the user is currently online or not. A role change on Site A triggers a sync event that carries the new role through the mapping rules and updates the user’s role on Site B accordingly. The user’s permissions on Site B stay current without any manual action from you or them.
The most common multi-site role mapping scenarios
Different types of multi-site networks have characteristic role mapping requirements. Understanding the most common scenarios helps you design your mapping configuration before you start the technical setup.
Configuring role mapping in Nexu User Sync
The Nexu User Sync plugin for WordPress role mapping and cross-site permission synchronization handles role mapping through the Sync tab on a per-connection basis. Each connection between Site A and Site B has its own independent role mapping configuration, which means you can define different rules for each site relationship in your network. Here is how to set it up.
Navigate to Nexu User Sync in your WordPress admin, open the Sync tab, and select the connection between Site A and Site B that you want to configure role mapping for. Each connection has its own sync configuration, including its own role mapping table, so changes here affect only this specific site pairing.
Before configuring the mapping, confirm which roles exist on each site. The role mapping interface in Nexu User Sync shows you the registered roles on the current site. For Site B, you will need to know the role slugs that your plugins have registered. You can find these in the Users screen on Site B, or check your membership or LMS plugin documentation for the exact role names it creates.
In the role mapping section, add a rule for each Source Role to Target Role translation you need. For a WooCommerce to LearnDash connection, you would add: Customer maps to Student. For roles that exist on both sites with the same name and should remain unchanged, you can either create an identity mapping (Subscriber maps to Subscriber) or leave them unmapped and configure a default fallback role that applies when no specific rule matches.
Always configure a fallback role. This is the role that gets assigned when a user’s source role has no matching mapping rule. For most multi-site setups, the fallback should be the lowest-permission role that still gives the user a functional account on Site B. On a LearnDash site this is typically Subscriber. On a community portal it might be a basic read-only participant role. The fallback prevents users from arriving on Site B with no role assigned, which in WordPress typically defaults to no permissions at all.
Before running the bulk sync with role mapping active, test with a single user account whose role you can verify on both sites. Trigger a manual sync for that user, then check their role on Site B. Confirm it matches your mapping configuration. If it does not, review the rule order and fallback settings before processing the full user base. Getting the role mapping right on a test account takes a few minutes and saves you from having to manually correct permissions for hundreds of users.
How role changes propagate in real time
Role mapping is not just an initial sync concern. It applies to every role change event that happens on a connected site after the initial setup. When a user’s role is updated on Site A, that change triggers a sync event that carries the new role through the mapping rules and updates the user’s role on Site B. This is where the real operational value of automated role sync becomes apparent.
Consider what this means for a membership or subscription business. When a customer upgrades from a Silver to a Gold membership on your main site, their role on Site A changes to reflect the higher tier. That change propagates automatically to your community portal, your LMS, and any other connected site. Their access level on every connected site updates within seconds without any manual action from your team or from the customer.
Equally important is what happens on downgrade or cancellation. When a subscription lapses and the user’s role reverts to a lower-tier or basic subscriber role on Site A, that role change propagates to all connected sites. Access to premium content on the LMS is automatically adjusted. Premium community permissions revert. The user’s access across the entire network reflects their current subscription status without requiring any manual deprovisioning work from your team.
Without real-time role sync, both of these scenarios require manual intervention. An upgrade that should give immediate access to premium content on the LMS waits until someone manually updates the role or until the next scheduled sync. A cancelled subscription that should revoke premium access continues to allow it until a human catches the discrepancy. These are not theoretical failure modes. They are regular operational problems for any multi-site membership or LMS business that has not implemented automated role sync.
Edge cases and advanced role mapping configurations
Most multi-site role mapping setups are straightforward one-to-one translations. But several edge cases come up often enough in real deployments to be worth addressing specifically.
Some WordPress setups assign multiple roles to a single user, particularly when using membership plugins that stack a plugin-specific role on top of the default WordPress role. When a user has multiple roles, Nexu User Sync evaluates the mapping rules in order of priority and applies the first matching rule. Configure your mapping so that the most specific or highest-privilege role is listed first in the priority order. The fallback applies only when no rule matches at all.
LearnDash supports group enrollment where students are assigned to a group that controls which courses they can access. Group assignment is separate from role assignment. Role mapping handles the role part (ensuring the user arrives as a Student rather than a Subscriber), but group enrollment typically needs to be handled by your purchase flow or a LearnDash-specific automation. Design your architecture so that role mapping and group enrollment are handled by the appropriate system for each.
When sync is bidirectional and both sites have very different role structures, you need two separate mapping tables: one for syncing from Site A to Site B, and one for syncing from Site B to Site A. Nexu User Sync manages this through the per-connection configuration, where each direction can have its own mapping rules. For corporate networks with centralized HR systems, it often makes sense to configure the central HR site as the authoritative source for role assignments and use one-way sync to push role changes outward to all connected portals.
Some roles should never be synced to secondary sites. Administrator accounts on Site A should almost never be synced to Site B as administrators, as this would give Site A admins full control of Site B’s WordPress installation. Configure your sync settings to either exclude Administrator from the sync entirely, or map it to a lower-privilege role on Site B such as Editor. Similarly, any role that carries elevated permissions on Site A should be evaluated carefully before being allowed to propagate to connected sites.
The connection between role sync and access control quality
Role sync is ultimately an access control problem. The question it answers is: does every user on every site in your network have the right level of access at all times, without manual administration? For any site where access is meaningful (paid content, premium features, organizational tools, course materials), getting this wrong has direct business consequences: users who paid for access cannot get it, users whose access should have been revoked still have it, or support teams spend time fixing individual accounts rather than focusing on higher-value work.
Automated role sync via the Nexu User Sync plugin for automatic WordPress user role and permission sync across multiple sites resolves this by making the correct role assignment a consequence of the user event, not a subsequent manual task. When a customer upgrades, their new permissions appear immediately everywhere in your network. When access should be revoked, it is revoked everywhere. The role structure you design in your mapping configuration becomes the operational reality across your entire network, automatically and continuously.
For membership operators, LMS administrators, and corporate IT teams, this is the practical definition of a well-managed multi-site WordPress network: one where the access control state reflects what should be true based on the data in your systems, not what was true the last time someone remembered to manually sync.
Customer on your store. Student on your LMS. Automatically, instantly, every time.
Nexu User Sync handles per-connection role mapping so every user arrives on every connected site with exactly the right permissions. Configure the translation once and it runs automatically for every registration, role change, upgrade, and cancellation across your network.
Finally got this up and running after some trial and error, and man what a time saver! The way it syncs roles between our main site and community portal is exactly what we needed. No more manually fixing permissions every time someone signs up. set it once, and new members just land in the right place automatically
Hey! this saved me so much time.
Got this during the summer sale and finally set it up
When WooCommerce adds a Customer role, does this guide handle mapping it to a non default role on