Best patterns for users in an enterprise/b2b app

Hi Everyone! I’m slightly new to Meteor, and right now I’m trying to build an apps which require a user system more suitable to businesses. I’ve looked around and have not found any articles about this yet. Is there a standard pattern/method to implement roles such as:

  • Admin Users for the system
  • Company/Manager Users who can invite other users
  • Normal users

Could we have meteor accounts-base make users without making sign-up publicly available?

I know this package exists too:


Slight edit with resources I’ve found that help with this (but not answer the question about patterns):


Visited the forum to post the exact same question and saw this thread. Thanks for posting this. I think if someone answers this question in database design perspective also, it would be really helpful.

Sorry If I am hijacking your question.

The relevant section of the docs at help you with two very important, enterprise-friendly options:

forbidClientAccountCreation Boolean
Calls to createUser from the client will be rejected. In addition, if you are using accounts-ui, the “Create account” link will not be available.

restrictCreationByEmailDomain String or Function
If set to a string, only allows new users if the domain part of their email address matches the string. If set to a function, only allows new users if the function returns true. The function is passed the full email address of the proposed new user. Works with password-based sign-in and external services that expose email addresses (Google, Facebook, GitHub). All existing users still can log in after enabling this option. Example: Accounts.config({ restrictCreationByEmailDomain: ‘’ }).

Couple this with the roles package from @alanning, you’ll have a good base to craft your accounts system. If you want to go more enterprise you can take a look at

Also, this blog post points out common mistakes like unknowingly allowing edits to the profile or publishing secrets.

I also suggest against using the profile field since it is freely editable by the user, unless you use allow/deny rules to prevent it.

From a database design perspective, since role information is not something that changes very often, I guess you can keep it within the user document itself. But if that’s something changing rapidly for you, or you have a really very large roles list, you may consider keeping it within another collection. But I suppose the defaults with the alanning:roles is quite fine.

You also have some other roles package alternatives here


@pasharayan This post helped me understand the logic better

1 Like

Thansk Serkandurusoy for this fantastic post!