Introduction

One of the first things new administrators notice when they get into Liferay is just how many different ways there are to group users. You’ll find Accounts, Organizations, Sites, User Groups, Asset Libraries, Segments, and Teams all sitting there in the menus. And then, layered on top, you’ve got roles to assign. It’s no wonder folks stop and ask: Which one do I actually use? When does it make sense to pick one over another? Can I mix and match?

This came up recently in the community, where my friend Christoph Rabel said:

Hi, one thing that's thoroughly missing are the concepts behind various Liferay things. For example Accounts. So you have this page: https://learn.liferay.com/w/dxp/security-and-administration/users-and-permissions/accounts And basically you learn how to create a account and that I can add users and so on to it. But what is it's purpose? What do with it? How can I use it in real world applications? Why do I even want to use it? And how does it relate to commerce? New users have a hard time getting into stuff because there is so much unclear.

Usually the docu explains a single thing, shows a few screenshots, but the big picture is missing. There was a great talk many years ago from Jorge Ferrer where he covered Organizations. It explained the "tight coupling with users" and it was quite enlightening to me. Again, I just checked, the documentation does not explain when to use Organizations. When should I create a site? Or a company/instance? Should I use accounts, organizations or groups or roles? 

The documentation is great at telling you how to create an Account or add users to an Organization — but not so great at telling you why you’d want to do it in the first place. I’ve been around long enough to remember Jorge Ferrer’s classic explanation of Organizations versus Communities, and I think we’re overdue for that kind of “big picture” conversation again, especially since Liferay has only added more options over the years.

So let’s talk through them. Not in isolation — that’s what the docs do — but together, so you can see how each one fits, when it shines, and how they can even complement each other.

Accounts: external relationships with self-service

Accounts exist to represent external entities you do business with — partners, customers, clients, vendors. The power of Accounts is that you can let those external entities manage themselves. An Account Administrator can add or remove users, decide who gets access, and assign roles without your intervention.

And yes, Accounts are deeply connected with commerce. Buyers, approvers, and account managers all need to work together to share carts, orders, and billing. Accounts give them the framework to do that while still giving you the oversight you need.

But don’t fall into the trap of thinking Accounts are only for commerce. Any time you need an external business to have a structured presence in your system — with its own users, roles, and self-service controls — Accounts are the way to go.

Organizations: modeling your internal hierarchy

Where Accounts look outward, Organizations look inward. They’re all about reflecting your own business structure inside Liferay. Departments, regions, business units — however your org chart is drawn, you can model it here.

The main advantage of Organizations is delegation. Instead of one central admin handling every user, you empower Organization Admins to manage their own slice: add people, adjust roles, and handle day-to-day administration. That becomes invaluable at scale.

There’s also a special twist worth calling out: the “sales organization.” You can model your sales team as an Organization and give them access to Accounts. That way, sales reps can act on behalf of customers — placing orders, changing addresses, or adjusting account details — while still being managed within your internal hierarchy.

And when an Organization needs its own Site, you can enable it. Suddenly that branch or department not only manages its users, but also has a full digital space for collaboration, announcements, or applications.

Sites: shared spaces for members

Sites are the foundation of Liferay’s digital experiences. They’re the spaces where you create pages, publish content, and deliver applications.

The key thing to remember here is that a Site defines a group of members. When you join a Site, you become a Site Member, and that membership grants you access to the Site’s protected content and functionality — the stuff guests or the general public can’t see or use. From there, you can assign Site Roles to tailor what members can do inside.

This makes Sites the natural way to gather people around a common digital experience. Whether it’s an intranet for employees, a partner portal, or a customer-facing knowledge base, the Site is the container. Membership is what ties the people together inside it.

Teams: fine-grained groups inside a Site

Sometimes a Site needs smaller, specialized groups. That’s where Teams come in. They live inside a Site and let you carve out specific responsibilities.

Maybe you’ve got a team that manages pages, another that handles web content, and another that approves workflow tasks. Everyone’s still a Site Member, but Teams let you fine-tune roles and responsibilities without having to build complicated structures.

Think of Teams as the way to set up ad hoc collaboration inside a Site, where you need more nuance than just “member” or “administrator.”

User Groups: convenient collections across the instance

User Groups are a flexible way to gather users who don’t necessarily share a Site or Organization. You can pull in anyone from the instance — employees, external users, even a mix of both.

The strength of User Groups is convenience. You can assign roles directly to a User Group, and every member automatically inherits them. If someone leaves the project, removing them from the User Group is all it takes. No hunting around through individual assignments.

User Groups can also have their own Site pages, giving you a lightweight way to give that cross-cutting collection a shared digital space. They’re perfect for temporary project teams, cross-department initiatives, or even mixed internal/external collaborations.

Asset Libraries: user groups for shared content

Asset Libraries solve the problem of reusing content across multiple Sites. Instead of duplicating documents, media, or web content everywhere, you centralize it in a library and connect it to as many Sites as you need.

But don’t forget: an Asset Library also defines its own membership group. The users who belong to that library are the ones who can access and contribute to it. And within that group, you decide who gets to update and manage content versus who just consumes it.

That makes Asset Libraries both a technical tool for organizing content and a user grouping in their own right.

Segments: dynamic, rule-based groups

Segments are all about defining groups on the fly based on rules. You might segment users by country, by language, by behavior, or by custom fields. As users match those criteria, they automatically fall into the Segment.

Most people think of Segments for personalization — showing different content to different users on the same Site. And that’s true, but they can go further. Because Segments are recognized as user collections, you can assign roles to them.

For example, in the global site, you could define a Segment called “Employees” where the rule is simple: anyone with an email address matching your corporate domain. Now you’ve got a dynamic group that automatically maintains itself, and you can assign global roles to it just like you would with a User Group or Organization.

Segments are powerful because they’re runtime constructs. You don’t manage membership manually — the system does it for you.

Roles: the glue that holds it all together

All these groupings — Accounts, Organizations, Sites, User Groups, Asset Libraries, Segments, Teams — are really just ways of collecting users. What gives those collections power are the roles you assign to them.

Roles are the glue that binds users to what they can actually do. Add someone to an Organization, and they get its roles. Put them in a User Group, and they inherit that group’s roles. Drop them into a Segment, and they pick up any roles assigned there.

Instead of sprinkling individual role assignments everywhere, you use these groupings as multipliers. Add or remove a person from the group, and their roles — and the access that comes with them — update automatically. That’s how you keep things manageable at scale.

Quick reference: which grouping to use when

Here’s a side-by-side summary to keep handy:

Conclusion

Liferay gives you a toolbox full of ways to group users. Accounts for external entities with self-service capabilities. Organizations for internal hierarchies (and special cases like sales teams). Sites for shared digital spaces where members come together. Teams for specialized groups inside a Site. User Groups for convenient collections across the instance. Asset Libraries for user groups tied to shared content. Segments for dynamic, rule-based collections that open the door to personalization and beyond. Roles tie it all together.

The trick isn’t just knowing what each one does — it’s knowing when to reach for which tool. Hopefully this walkthrough makes that picture clearer and gives you some ideas for structuring your own projects.

But I know every use case is different. How are you approaching it? Have you found clever ways to combine these groupings? Drop a comment, find me on Liferay Community Slack, join the conversation on discuss.liferay.com, or swing by one of my "Ask Me Anything" sessions. I’d love to hear your take.