Inviting and managing users inside a workspace

Fireback accelerates backend and mobile app development, offering powerful code generation tools and standardized architecture. With seamless backend integration and streamlined workflows, Fireback expedites the creation of robust and scalable apps.

Each workspace, contains a list of user to role connection, simply many users with different roles can exist. There are several ways that a user could be added to a workspace, or get different roles.

When a user creates a public account (for cloud projects for example), fireback creates his account, passport (email or phone) and an empty workspace. This is not optional, and the reason is every project at some point will need team (workspace) support, where multiple people with different access roles could modify or query the data. Considering this fact, it's always good to design database and your backend - as we did - to support fully the multi-user multi-team structure.

Now, when you are admin in the workspace (or PERM_ROOT_WORKSPACES_INVITE at least) you can add users into the workspace. This is complex matter in fact, taking into account all different methods that you need to cover, (which we covered in fireback).

Invite vs Add

In invitation system, you do not create a new user in the system, rather sending an invitation, in form of an email or sms code, and give link or instructions how he can join the system. They will complete sign-up by themselves, while having their own account, would be joining to the workspace with role specified in the invitation. This is common on cloud projects, apps like slack, google cloud, etc.

In adding method, you create account with a password for them, administration might be able to see the password, and the signup process is complete. This is suited for internal software, ERP or IT department which there is direct management for each person. In such cases, you can even prevent users to create account or workspaces.

Different scenarios of invitation

When we want to add a person in the system of ours, there are few situations that would appear.

Inviting a complete stranger to the system

Assume you are admin in a workspace, and you want to invite a friend, which never used this product. He either needs to create an account with email or phone (other options might be available).

For this, you need to send an invitation via email, and he would see a signup form, He chooses his own email address if he wants to, means you just give that person a permission to join, and primary email you have used in fact is not forced, and it was a contact method.

After he completes the signup, he will be added as well to your workspace.

Inviting a user with forced passport

This case is similar to the case above, just the differece is you want that user join to the app on very exact same email address you invited them, or phone number. This is suited for company wide email addresses, where everyone has to have same email address company designated for them.

Inviting a user which has an account in the system

In this scenario you will send invitation to a user which has an account in the system. If you are not forcing the passport, they might be able to accept the invite with the same account they have. Meanwhile they would login to their account, they could be asked which workspace they like to work on, and switch between them with complete privacy.