User groups & permissions
Setting up user groups and defining permissions.
Setting up user groups and permissions in your Softr apps helps you control who can access what information. Whether youโre building a Client Portal, an Internal Tool, or any other business application, you can group users by shared needs and set permissions to define exactly what they see and how they interact with your data.
Use permissions to:
- Restrict access to certain pages or blocks.
- Control which records users can read, edit, create, or delete.
With these tools, you can easily build secure, dynamic, and personalized apps.
User Groups
User groups are at the core of Softrโs permissions system. They let you organize users based on their access needs and are the foundation for applying visibility and access rules throughout your app. Softr provides the following types of user groups:
Default User Groups
- Non-logged-in Users: Users who access the app without logging in are automatically placed in this group. This is ideal for public-facing content such as landing pages or public directories.
- Logged-in Users: Any user who logs into your app is part of this group. You can use this to gate content and actions exclusively for authenticated users.
Custom User Groups
Custom user groups let you set detailed access rules for specific subsets of logged-in usersโlike clients or employees. You can make these groups either dynamic or static:
- Dynamic user groups: Defined by rules based on user attributes or subscription tiers. When logging in, users who meet those criteria are automatically added to that group.
- Static user groups: Defined by manually adding users to the group, with no dynamic rules involved.
Custom user groups are available on Professional, Business, and Enterprise plans.
Example:
- The โAdminโ group can access admin dashboards and team metrics.
- The โClientsโ group can access their own projects and tasks.
Types of permissions
You can set up permissions in Softr at two levels: UI elements and data.
UI element visibility controls which pages, blocks, and actions each user group can see, while data permissions define which records or data subsets they can access within a block. This section covers the Softr features you can use to configure these permissions.
UI Element visibility
You can manage access at various levels: Page, Block, and Action buttons.
Visibility rules are hierarchical. If you restrict a page to a user group, everything on that pageโblocks and elementsโis also limited to that group or its subsets.
Page Visibility
Page visibility lets you control who can access an entire page in your app. Assign pages to predefined user groups so only the right users can see restricted pages like salary information or the companyโs revenue KPIs.
Example: In a Client Portal app, clients can only see their company page and projectsโ status, not other clientsโ information. Admins can see additional pages like Clients, Invoices, Teams, and Contracts.
Block Visibility
Block visibility lets you control which user groups can see specific blocks on a page, ensuring a personalized experience. You can also tailor block visibility for different devicesโdesktop, tablet, and mobile.
Example: In a Sales CRM app, admins can see the blocks showing the revenue metrics, while regular employees can only see the blocks with quick links.
Data permissions
Data permissions let you control which records users can see or interact with. You can apply these permissions at the block, action, or app level.
Action Visibility (aka Permissions)
Set action visibility for user groups to control who can interact with buttons like add record or edit record. You can also use conditional filters to show or hide actions based on custom criteria.
Action Visibility is available for Professional, Business, and Enterprise plans.
Example:Only Admins can see the Edit button in a client portal app to edit project details. Clients will only see view-only project details.
Conditional Filters (aka record filtering)
Conditional filters let you filter data for each logged-in user by applying user-based conditions or other record information, URL parameters etc. For example, users can see only records tied to their email (e.g., show projects assigned to this user).
You can also set filters based on record fields, like task status or category, to show relevant records to everyone. (e.g., show records that donโt have โDoneโ status).
Example: In a Task Management app, logged-in users can view only the tasks assigned to them.
Global Data Restrictions
Global data restrictions let you define restriction rules of who can view, create, edit, or delete data at an application level.
You only need to define them once, and they automatically apply to all blocks, ensuring consistent access control and preventing accidental data exposure. This is especially handy if you know specific rules and cases upfront when access to view, edit, or delete will always be restricted to certain groups - and instead of defining those rules at every block level, you define them once for the whole app.
Types of Global Data Restrictions
- Record-Level: Manage visibility or editing rights for entire records.
- Field-Level (coming soon): Restrict access to specific fields within a record for certain users.
Example (record level): In a client portal, apply a โViewโ restriction so clients see only their project data. By matching records to the logged-in user's email, you ensure a private and secure experience where users cannot access data belonging to others.
Example (field level): In an HR portal, you might want the HR manager to view and edit all the employees' personal information, but employees are never allowed to edit their salary information.