Job board employees and clientele collections


I’ve been building first app for my business. The app works as a job board to connect my employees to suitable clients.

For now it has been really steep learning curve, and I have been able put together “the big picture”. I understand how Adalo works, but there are some essential things that still need training and therefore I would be most thankful for insightful views and advise.

So, here are my questions:

  1. Am I to use the original “user” database collection for all my clients and employees?

In my mind the most logical solution would be to build two different database collections, first for my employees and second for the clientele. So using only one collection for both would seem to be a bit illogical, as it would pose a risk for mixing things up and also because the two user groups have different attributes.

Also, I would very much like to use same login interface for both parties, but depending which one logs in to the app, the following screen would be different: clientele could add a new job, whereas employees screen would include different jobs(that clientele add at their pleasure).

Following questions are linked to the first question, based on the outcome of this question.

If I am subjected to use only the original “user” collection, is there anyway to separate the two user groups when they log-in and direct them to their respectable starting screens?

If I am to do as I originally thought, then how can I build two different user collections that still hold the same functions as the original user collection has?

Best regards,


Unless there is a method I’m not aware of as of yet, only the “users” collection that’s pre-established with each new app will provide the necessary attributes for a “logged in user.” You certainly could have a username and password field for a login screen tied to a separate users Collection that you created, and even set the “log user in” variable when tapping submit, but I believe when that variable runs, it’s going to check the supplied username and password against the prebuilt users Collection, which then would return a “user doesn’t exist” error; that’s my understanding, anyway, as I haven’t been successful with any other method, similar to what you’re wanting to do.

Now, the workaround having all your users in the users Collection. You can create separate collections for users versus admins, for example, and create relationships between those and the users Collection to help break things down a bit for internal organizational reasons, but to display separate screens after login, you’ll have to use the true/false component in the users Collection, create a variable redirect screen after login, and direct users based on that T/F component.

For example:

Create the T/F field in users Collection and call it whatever you want (I use isAdmin for easy sorting). Whoever your admin users are, set that component to True on their account.

From the login screen, have it direct to a splash page (this is a good opportunity to create a “loading” screen and apply a preloader component to that screen).

Then set the splash screen’s actions to direct to the admin page IF the logged in user “isAdmin” (set to true). Otherwise, direct to the user’s screen if the logged in user is not “isAdmin” (set to false).

You don’t need two collections for both user types. You can do this with a one collection using a true/false property like @preptogether mentioned to identify if that user is a client or a employer or you can create two apps for both user types!

You can watch this video made by Victor : Adalo tutorials: admin and user access to different screens. UPDATE in the description - YouTube

And this video made by Adalo Team too : #TwoMinuteTuesday | Multi sided Apps - YouTube

Thank you


thank you both for valuable answers!

True/False would be most suitable for my purposes if both parties used mobile, but I’ve decided to use mobile for my employees and web app for clientele.

Best regards,


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.