Introduction
Users are the backbone of any application or product, do you agree? An application or a product is built to solve a pain point for a target user in mind. Or, it may be built to make the life of the target user a tad easier.
From that perspective, I wanted to write about all about Users, User Groups, Data Restrictions and Page Navigation rules in Softr. In my previous post, I navigated the length and breadth of Softr, a powerful No Code tool from a 50,000 feet. Whereas, in this post, let's take a closer look at a few aspects, in fact one of the most important ones.
💡
I'd recommend taking a quick look at my previous post as I plan to continue building the
Gated Community App that I started earlier.
Users and User Groups
As we all know, Users are the entities that use the application built. If the application is a CRM, then the end users can be from the Sales and Marketing team. If the application is a Student portal, then the end users will most probably be students. If the application is a Plant lovers community, then most probable end users can be people who share a love for plants.
User Creation
So, how are users created in a Softr application? There are quite a few ways:
The most common one is through Sign up feature available in the application you build. For example, I have a Sign up button in the Community key app. When a user signs up, they will be added to the users list in Softr.
In certain cases, you may want to add users manually. Usually while we are in the process of building the application, we may need some test users real quick. In such cases, this option comes in very handy.
When you click on Add Users, you should see the screen below 👇
Email is mandatory for a user in Softr. You can either generate a temporary password or generate a magic link and share it with the newly created user.
There is also an option to bulk upload users. We may have captured our users in a Google sheet or a Microsoft excel file. If we want to move those data at one shot, the import users option is very useful and saves a lot of time. Just that the data should be in the format Softr expects. Trust me, it's very simple 😁
In the Add User screen, there is another tab which is for Bulk Import. Here is where you can upload your csv files
The other common option is to connect to an external data source, where the data source can be any one that Softr supports. Eg., Airtable, Google Sheets, SmartSuite, HubSpot and BigQuery. Once you connect to an external data source, your existing users from that source come in to Softr, as well as if a new user signs up, they are added to that external data source too.
In my Community Key app, I use Airtable as the external data source. Here is the detailed documentation to connect to Airtable from Softr. In my case, Base Community Key is the name of my Airtable Base, and Users is the name of the table where all users are stored by default.
💡
In my previous post, I used Residents as the table for newly created users. I made quite some changes to my Base as it is a work in progress app. You can refer to
my Airtable base here as this is the latest.
If your organization has multiple applications and one among them is the one built using Softr, there are chances that users may come from these other applications too. In that case, we may need an automation tool like Zapier or Make. We build a zap connecting the other application (which can be anything from a Google Sheet to a Monday.com) to Softr and create users.
Similar to the above, we can also use Softr's API directly through code or using automation tools mentioned above.
Key points to remember about Users
Highlighting two key points when it comes to Users in Softr.
There are Internal and External Users. Internal users are the members who collaborate on an app. External users are the members who sign up and use the application. In each plan, there is an allowed number of Internal and External users. When you choose your pricing plan, estimate on how many users will you collaborate with and those that will use your application.
If you connect to an external data source, then deleting users in your data source will not affect the users in Softr. This is why sometimes you may see "User already exists" inspite of deleting the user from the external data source. If you want to delete an user manually, you should do it from both the places
User Groups
This is an extremely useful feature in any application. There will always be different groups of users, where each group can have a different business role. What is the purpose? Security and Personalizing the user's experience are the top two reasons in my opinion.
And what does it mean to have a different business role? Technically it means based on the role a user is assigned to, they may be allowed to do certain actions, view certain pieces of information, and restrict access to all modules of an application.
By default, Softr provides 3 different User groups, All Users, Logged in users, and Non logged in users. We can use these to set a page and a block's visibility.
For example, in the Community Key app, the list of Residents should only be viewed by Logged in users and not everyone. Whereas, the Market News page can be viewed by all users.
We can take this one step further and add Custom groups too. Typically, based on a condition or based on a user action, a user can be mapped to a custom user group.
For example, I defined 3 different Custom user groups in the Community Key app. They are Admin, Residents and Vendors.
In order to define a Custom user group, click on + Add user group
Let's say I want to add a group called Beta Testers to this app, then 👇 is what I will do
When I click on Next, I have two options. One is to add users manually which is quite straight forward. I probably can create a few users upfront and add them to the Beta Testers group and invite them to test my app.
The other option is to define a condition like so 👇
I can design a "Join the waitlist" button. When a user submits their email while clicking on this button, I can pass a hidden field with value as Beta Tester and use it to add the user to the Beta Testers group.
It's up to the developer's creativity and business logic to branch users to different user groups.
Now that we've defined different user groups, we can add them under the visibility section. For example, in the Community Key app, the Resident Onboarding screen should be viewed by Logged In users who belong to the Residents group only. There is no need for Vendors to view this page, is it not?
I can even define a common page called Onboarding and add two blocks, one for Residents and one for Vendors. I can then set the appropriate visibility conditions at a custom user group and show/hide blocks. This way, I can reduce the number of pages.
💡
Psstt...I'm already making that change 😁
Once you create a custom user group, it's not meant forever. You can very well edit, duplicate and delete the created group.
Data Restrictions
Data Restrictions in Softr allow setting data level access based on conditions. They are applied to the entire app and not at a page or block level that we saw earlier.
What does data level access actually mean? Let's take a simple Employee Management app. There are employees, projects and tasks. Each employee has a Manager. A Manager should only be allowed to add/edit/delete tasks of employees who report to them. Likewise, an employee should be allowed to view the tasks assigned to him/her and not the tasks of every other employee. This becomes very crucial when there are multiple entities in an app.
💡
Defining view access based on conditions is available in all plans. Whereas defining create, edit, delete level restrictions is only available on business plans.
Let's see how to define a restriction in the Community Key app. It is the third tab when you click on users on the left pane.
Let's add a data restriction to the Residents table
Now, Vendors will be unable to view any of Residents details. I signed in as a user with Vendor role and clicked on Residents menu. Due to the Data Restrictions set up, it throws an error message as below 👇
This particular example may not be a great one, it's more to show what happens when a user tries to perform an action when there is a restriction.
Defining the right set of conditions becomes a game changer with showing and hiding relevant data to the relevant user.
Page Navigation
Let's move on to the final section of today's post, which is nothing but Page Navigation. These are a set of rules that can be defined in terms where to redirect a user belonging to a particular user group after Sign up, Sign in, Sign out and to an Unauthorized page.
Click on the second tab User groups
I just defined the page rules for the user group Residents. Isn't it easy to define such rules at one place?
Conclusion
User groups, Data restrictions and Page rules should be one of the primary steps to be performed while building an application. Good amount of thought process should be given while deciding the groups of users, and the capability of each group.
If that's done well, designing blocks and defining visibility conditions will be a cake walk.
To know more about the progress of Community Key check my tweets. Have an idea, want to build an app using Softr? Sign up using my affiliate link to get one month of Softr's Professional plan free for a month. Need any help using Softr, send me a DM here.
What are you waiting for, let the music begin 🎵😁
