Multi-Store, Four-Role User Management Scenario on Joomla 5

Hello,I’m building a multi‑store Joomla 5 site that needs four distinct user roles within each store:

1. Owner
2. Administrator
3. Escalated
4. Basic

Store & Role Requirements

• Each store has exactly one Owner, who cannot be removed from that store (except by me, the site’s super admin).
• ​​​​​​​Owner and Administrator share the same functional privileges (they can add/remove store users, rename the store, view financial data, etc.). The only difference is that the Owner cannot be removed from the store, whereas an Administrator can be removed by an Owner (or possibly another Admin).
• Escalated users can see sensitive information—like financial records, inventory coordination requests, and internal news—but cannot manage user accounts or rename the store.
• Basic is the lowest role: no user management, no financial data. They can see general items like store news, benefits, and possibly place inventory requests.

Multi-Store Two-Level Structure

• I (the site owner) am the top-level super admin.
• Each store’s Owner (and possibly Admins) manage the internal users of their store from the frontend only.
• No store admin should see or manage users from other stores.
• ​​​​​​​When a store admin creates a new user (e.g., Basic or Escalated), that user should automatically be assigned to the correct store’s user group, without forcing the admin to pick from all groups in a drop-down list.

Goal With Community Builder

1. Frontend User Management: We don’t want store admins in the Joomla backend. We need a CB list or menu item that shows each admin only their store’s users.
2. ​​​​​​​Automatic Group Assignment: Possibly using CB Auto Actions to detect which store admin created a user, then auto-assign that new user to the relevant “store user” group and the correct role (e.g., Basic or Escalated).
3. Role Distinctions: We’d like to enforce or replicate the logic that an Owner can’t be removed from the store, while Administrators can, etc. We realize that might be partially a policy decision, but if CB can help lock that down, that’s great.
4. Additional Plugins?: Are there other paid CB add-ons (besides CB Auto Actions) that I’d need for advanced conditional fields, multi-role assignments, or to ensure each store admin can only see/edit their own store’s data?

My Questions

1. Is this four-role setup (Owner, Admin, Escalated, Basic) with strict store isolation fully achievable using Community Builder on Joomla 5?
2. Do I only need CB Auto Actions (for automatic group assignment) or are there additional plugins you recommend?
3. How could I best handle the “Owner cannot be removed” rule? Should I rely on a manual policy, or is there a CB feature to prevent certain group/role changes for the Owner?
4. ​​​​​​​Thank you for your help! I look forward to your guidance on the best way to configure CB for our multi‑store, multi‑role user management needs.

Best regards,RanD

I assume you already have the store handled with something like HikaShop or Shopify as both have multi-vendor plugins? We don't provide a storefront. We only provide subscription management using CB Paid Subscriptions. Implementation may be impacted based off whatever storefront you're using.

Is this four-role setup (Owner, Admin, Escalated, Basic) with strict store isolation fully achievable using Community Builder on Joomla 5?

To a degree, yes. We don't have functionality for assigning a user to another user exactly, but CB Moderators cannot editor users above or adjacent to them in a user group hierarchy. Example as follows.

Public
- Registered
- - Admin
- - - Owner

With the above Owner can edit Admin and Registered. Admin can edit Registered, but cannot edit Owner. This however only applies to profile data and not other content (e.g. CB Activity, CB Gallery, etc..). In the above case Admin and Owner would have CB Moderator permissions. In order to do user to user assignment you can implement that with CB Auto Actions as you'll be able to redirect away from edit operations they're not permitted to have.

Backend utilizes Joomla permission system so you'll be able to use that to adjust what backend features each usergroup has access to.

Do I only need CB Auto Actions (for automatic group assignment) or are there additional plugins you recommend?

As it stands it seams like that's all you'd need.

How could I best handle the “Owner cannot be removed” rule? Should I rely on a manual policy, or is there a CB feature to prevent certain group/role changes for the Owner?

You can block user deletes with CB Auto Actions.

Hi Krileon,Thank you for your detailed reply regarding our multi‑store user management scenario.To clarify, we are not using a storefront solution like HikaShop or Shopify. Our goal is to build an intranet portal where each store has its own access area. Our primary requirement is to manage subscriptions and user profiles, so that each store operates independently with strict user isolation.Our Requirements Recap:

1. Store-Specific Roles:
   • Owner: Full control over the store (cannot be removed except by a Super Admin).
   • Administrator: Can manage users (add/edit/remove) except for Owners.
   • Escalated: Can view sensitive information (financials, inventory requests, etc.) but cannot manage users.
   • Basic: Limited access; cannot view financials or manage store settings.
2. Store Isolation:
   • Each store’s admin and users must only see and manage data for their own store, with no cross-store visibility.
3. Frontend User Management:
   • We want store admins to manage users exclusively through the intranet portal (frontend) without accessing Joomla’s backend.
   • The plan is to utilize a hierarchical user group structure (e.g., Public > Registered > Admin > Owner) with CB Moderator permissions so that, for instance, an admin can only edit users below them (e.g., Registered) but not Owners.
4. Automatic Group Assignment & Protection:
   • We need new users, when created by a store admin, to be automatically assigned to the appropriate store user group using CB Auto Actions.
   • Additionally, we want to block deletion of Owner accounts via CB Auto Actions.

Follow-Up Questions:

1. With a hierarchical structure like:
   • Public
     └ Registered
     └ Admin
     └ Owner
     – can you confirm that a CB Moderator in the Admin group will only be able to edit Registered users (and not Owners), at least for profile data?
2. For user-to-user assignment:
   • Could you provide more details or examples on how CB Auto Actions can be configured to redirect or block edit operations when a store admin attempts to modify users above or adjacent to them in the hierarchy?
3. Regarding the protection of the Owner role:
   • How does the “block user deletes” functionality work in CB Auto Actions? Will this completely prevent non‑Super Admins from deleting an Owner account?
4. Are there any limitations or considerations with this approach regarding non‑profile content (such as CB Activity or Gallery) that we should be aware of?
5. Lastly, do you have any best practices or recommendations for configuring this hierarchical structure and ensuring strict store isolation for our intranet portal using Community Builder on Joomla 5?

I appreciate your assistance and look forward to your guidance on these points so that we can move forward confidently with our intranet portal implementation.Best regards,

Is this a single business that oversees multiple stores? In that case mixing data in a single install is fine. If each store is an independent business you're unlikely to do this on Joomla as you'd violate some data laws not keeping data isolated. Community Builder works amazingly well for intranets, but adding multi-site into it might be a problem.

Each store’s admin and users must only see and manage data for their own store, with no cross-store visibility.

Joomla really doesn't have any functionality for that. If you need data isolation then each store should be its own Joomla install. I would just do that as subdomains for your intranet.

We want store admins to manage users exclusively through the intranet portal (frontend) without accessing Joomla’s backend.

Frontend user editing is fully functional. User creation however would require a custom form utilizing CBs API or logging out and using registration. Frontend user creation while logged in will be something added in CB 3.x.

We need new users, when created by a store admin, to be automatically assigned to the appropriate store user group using CB Auto Actions.

You'd need a means of identifying users to specific stores (e.g. store number) or your custom frontend form for creating users should ideally handle that. Something like RSForms for example.

Additionally, we want to block deletion of Owner accounts via CB Auto Actions.

There is no frontend user deletion. CB is designed with Joomla backend usage in mind. You should ideally use permissions to restrict what owners have access to in backend, but that'd be a problem for multi-site. So for frontend to have user deletion you'd need a custom implementation and that could then be restricted.

can you confirm that a CB Moderator in the Admin group will only be able to edit Registered users (and not Owners), at least for profile data?

You'd need the following structure for that.

Public
- Registered
- - Admin
- - - Owner

Could you provide more details or examples on how CB Auto Actions can be configured to redirect or block edit operations when a store admin attempts to modify users above or adjacent to them in the hierarchy?

I'm not sure what example you're looking for. It's doable by acting on the appropriate trigger. I cannot provide you with an exact example without an active subscription.

How does the “block user deletes” functionality work in CB Auto Actions? Will this completely prevent non‑Super Admins from deleting an Owner account?

It blocks access by redirecting away and interrupting the process. It can prevent whomever you want from editing or deleting whomever you want as you can define the conditions.

Are there any limitations or considerations with this approach regarding non‑profile content (such as CB Activity or Gallery) that we should be aware of?

Yes, there's no access hierarchical access checks for content other than profile edits. So if they've CB Moderator permissions they can freely modify all other content. However you maybe able to avoid making them CB Moderators entirely. We do have a trigger for our permissions check that CB Auto Actions can extend and that can be used to grant profile edit permissions to whomever you like. So there are alternative solutions available.

Lastly, do you have any best practices or recommendations for configuring this hierarchical structure and ensuring strict store isolation for our intranet portal using Community Builder on Joomla 5?

I've never configured a multi-site or multi-tenant intranet with Joomla before so beyond the above I don't have much to recommend. If each store were its own Joomla site your configurations would be substantially easier, but would of course require additional maintenance maintaining multiple sites.

Hi Krileon,Thank you again for your detailed replies regarding our multi-store intranet requirement on Joomla 5. We appreciate you clarifying the possibilities and limitations.To ensure we're on the right track, could we quickly summarize our goal and understanding, and ask a few follow-up questions based on your last response?
 Our Goal:

• Create a multi-store intranet where site admins set up "Stores".
• Each Store has a designated "Store Admin" (or Owner).
• Store Admins must manage users (Add, Edit, Delete with "Basic" or "Escalated" roles) only for their own Store, entirely via the frontend portal.
• User roles (Basic/Escalated) determine access to standard Joomla content (Articles, Categories, Modules for things like News, Financials, etc.).

 Our Initial Thought:Based on the requirement for frontend group/store management, we were initially considering this approach:

1. Use CB GroupJive: .
   • Structure: We planned to represent each 'Store' (Store A, Store B, etc.) as an individual CB GroupJive Group.
   • Management: The designated 'Store Admin' user would be assigned as the Manager/Owner of that specific GroupJive Group.
   • Functionality (Our Assumption): We crucially assumed GroupJive provides built-in frontend tools for these assigned Managers. We expected these tools would allow the Store Admin (logged into the website frontend) to easily:
     • Add/Invite, Edit, and Remove members, but only within their own Store's Group.
     • This would ensure isolation between stores.
   • Roles: We also hoped GroupJive's Owner/Manager roles might align with our 'non-deletable Owner' requirement.
2. Use Joomla User Groups: To assign the specific roles (e.g.,
   Code:

   Store A - Basic
   ,
   Code:

   Store A - Escalated
   ).
3. Use Joomla ACL: To control access to Articles, Modules, etc., based on these Joomla User Groups via standard Access Levels.

 Our Questions for Clarification:Could you please help clarify the best path forward within the CB ecosystem?

1. GroupJive Suitability: Was CB GroupJive not mentioned because it doesn't fit this requirement well, or was the focus simply on core tools + Auto Actions? Does GroupJive offer a more integrated solution for frontend member management by designated managers compared to the Moderator/Auto Actions approach?
2. Frontend Creation/Deletion with GroupJive: Does using CB GroupJive potentially overcome the significant limitations you mentioned regarding frontend user creation and deletion by group managers? Does it offer built-in tools for this?
3. Recommended Approach: For our specific goal (Store Admins managing users via frontend + role-based content access), would you recommend the GroupJive + Joomla ACL path, or the Moderator Permissions + Auto Actions + Joomla ACL path?
4. "Owner" Role: What is the recommended way to implement the "non-deletable Owner" feature – is this typically handled by a GroupJive role setting or best enforced via a CB Auto Action rule?

 We understand the complexities, especially around multi-tenant concepts on a single Joomla install, but want to ensure we're using the CB tools in the most effective way for our single-business intranet needs.Thanks again for your invaluable guidance!

GroupJive Suitability: Was CB GroupJive not mentioned because it doesn't fit this requirement well, or was the focus simply on core tools + Auto Actions? Does GroupJive offer a more integrated solution for frontend member management by designated managers compared to the Moderator/Auto Actions approach?

CB GroupJive was not mentioned because you specifically mentioned the ability to edit users. Groups are isolated communities. Their owners cannot edit users. They can simple manage the users status within that group. As in they can remove users from the group, invite them to it, ban them from it, or even promote them to moderators or administrators of that group. If you don't need group owners to be able to edit the profile data of users within that group then yes this would be a perfect fit for you.

Frontend Creation/Deletion with GroupJive: Does using CB GroupJive potentially overcome the significant limitations you mentioned regarding frontend user creation and deletion by group managers? Does it offer built-in tools for this?

Users are not created within groups, but they join groups. So the user must already exist through normal registration.

Recommended Approach: For our specific goal (Store Admins managing users via frontend + role-based content access), would you recommend the GroupJive + Joomla ACL path, or the Moderator Permissions + Auto Actions + Joomla ACL path?

If you use CB GroupJive you don't need any special ACL requirements as they're self contained communities. If you need owners to be able to edit the profiles of other users then the moderation permissions and ACL is basically your only option here.

"Owner" Role: What is the recommended way to implement the "non-deletable Owner" feature – is this typically handled by a GroupJive role setting or best enforced via a CB Auto Action rule?

Nobody can delete owner from a group in CB GroupJive except Joomla super users or CB Moderators.

My recommendation would probably be to explore CB GroupJive more and see if it can fit your needs, but to also modify your needs. So for example I would forego letting owners modify the profiles of users. Let users register themselves or let a site administrator manage that task. Owners would strictly be responsible for their Group only. This provides a safer environment I think and helps better protect the privacy and data of the users.