Do I need a separate user role table for my Vendors, Customers, Employees, Contacts, etc.?

If you want a group of users to log into your app to access information or perform an action, then you'll need to create a user role table for that group.

However, in some cases, you'll need just the user role table, and in other cases, you will need both a user role table and a regular table to keep track of the groups and users accessing your app.

 

User role tables offer the same options as regular tables, including the ability to add new fields and set up rules. Additionally, user role tables allow users to set up passwords for secure access to your app. For more information on user roles, click here.

 

Here are some examples to help you choose the right option for you:

Two Tables

If you have multiple users associated with a single entity, then you'll need to set up a user role table for the users and a regular table for the entities.

For example, let's say you have a list of businesses in your app stored in a table called Clients. Each Client has multiple people working for them that you need to log into the app.

You'll keep your regular Clients table and then create a new, connected Contacts user role table. Each Contact would be connected to the Customer (business) they are working for. This will allow you to show each Contact only the information for their own company and to let them add/edit information only for that company.

Another example of this is when you're tracking employees and their departments in your app. Departments would be a regular table. Employees would be a connected user role table so that employees can log in. 

User Role Table Only

If, on the other hand, multiple users can't or won't be associated with a single entity, then you only need a single user role table. 

Going back to the Clients example, if each Client is an individual person who needs to access your app, then you would have a single Clients or Customers user role table.

You'll still be able to store any non-user-related information about the Client in each record because user role tables have the same options that regular tables do for storing information.