In each application there are concepts like users, customers, etc. and some part of the application tries to manage them. For example:

1. keeping the information of people, organizations, firms, etc.
2. managing users (people who work with the system)
3. managing customers (people who purchase goods/services)
4. distinguishing customers, from users, from ordinary people, etc.
5. ...

Do we have a universal term for that area of each application (that subsystem, that module, that whatever)? Or if I want to ask more precisely, can we package customers, users, people, organizations, etc. all in one module, and name it like X? Is this a correct taxonomy of subsystems?

Update: Is Entities a good name?

closed as unclear what you're asking by Kilian Foth, user40980, BЈовић, Bart van Ingen Schenau, GlenH7 Jul 31 '13 at 17:18

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • the database? or it's schema? – jk. Jul 29 '13 at 6:45
  • 2
    After reading your question multiple times I think you mixed up two different things: user management and some kind of CRM (Customer Relationship Management). – Uwe Plonus Jul 29 '13 at 6:50
  • 1
    I'd call them "contacts". That could include users, customers, custombers-to-be, organisations and gentlemen that politely ask you to return the 100k you borrowed from them. – Joachim Sauer Jul 29 '13 at 7:27
  • 1
    I think you have something like an directory (LDAP, active directory in mind) where you store information and have a sort of ACL (Access Control List) in terms of authentication and authorization. – cinhtau Jul 29 '13 at 7:40
  • 1
    Entities is a bad name. Everything is an entity. – Tulains Córdova Jul 29 '13 at 13:27

This situation is a typical one for people who are new to building systems. The key here is about levels of abstraction which are not yet complete in your design.

Some typical taxonomy would be...

Contacts - anyone the system knows about.

Users - Contacts that need to access the system in some capacity.

In turn those Users could also be

  • Customers who've purchased in the past.

  • Staff who work in the business.

  • Suppliers who you purchase from.

Basically you refer to them at the level of abstraction that is important to you at that stage in your action or planning. There is nothing stopping a User from a member of Staff and a Customer for example.


One of the products of my company is a web application meant to handle communication between agents and their clients for a company which doesn't sell directly to the end buyer but rather sells to agents.

Both the agents as well as the clients must be associated with a user account in this system, but the agents have the power to manage its clients any way he or she pleases, since they belong to that particular agent. The way we handle authorization is not by establishing what agents and clients can do but rather assigning roles to the users. The role of a user is its authorization essence without necessarily being associated to a particular user. When the agent adds a new user, that user automatically has client role, since the way it is setup, the user of a particular role can create new users of an inferior role and client roles, not having any role inferior to it, cannot create new users. Similarly, we have administrative roles which are superior to agents which can create and manage any agent or client role, but cannot create other administrative roles.

There exists one super-user account which can create and manage users with administrative roles, and of course, everything else. (How does a super-user get created? It doesn't. The username and password are established upon installation, and that username and password overrides any role or authorization.)

We call the section where users are created and managed and, in general, configuration of the behavior of the web application for said user since this is separate from the normal functioning of the web application, the backend. The front-end, on the other hand, represents the part concerning the buying and selling of products (anything which has nothing to do with the behavior of the program, in short). Granted, backend is traditionally used to mean the part of the web application that the users don't see, so perhaps it wasn't the best name. However, I thought I'd share this since it may be of use to the OP or anyone else reading.

Not the answer you're looking for? Browse other questions tagged or ask your own question.