Let’s say you’ve got an app, and you want to allow multiple companies to access and use the same app.
- The primary benefit here is that, as a developer, you only have one app to support.
- If you were to create a copy of said app, one for each additional company that wanted to use it, then you’d have to support all those apps.
Any changes made to functionality (column structure, views, actions, automation, etc.) will need to be duplicated on each additional app.
- This then translates to hours of “extra” work you’ll need to do.
- This keeps everything inside one app, so as a developer you only need to support that one.
- Also, each company that suggests an improvement to the system is benefiting everyone.
- a “Companies” table
- a “Users” table - that’s a child to the Companies
- other tables that then filter based on data from tables “higher” in the database
- Like a “Clients” table being filtered to only show the “User_Assigned_Clients”
- Or a “Projects” table being filtered to only show records based on the “Project_Client_Link” being present inside the “Clients” table
The process involves:
- Creating a [Company_Master_Email_List]
- Creating an automation to keep that list updated (based on changes to the user table)
- Applying cascading security filters (Companies filters first, then Users, then everything else is based on those two)
—| Table of Contents |—
00:00 - Intro
00:29 - Benefits of single-app vs. multi-apps
01:14 - Required tables
01:44 - Key to how it all works
02:28 - Adding [Company_Master_Email_List]
02:57 - Creating an action to set the master list
04:15 - Running the action
05:22 - Creating a REF action
07:11 - Creating a BOT to keep things updated
08:31 - Bot condition for when it should run
09:06 - Creating a new task for the bot
09:55 - Actually implementing the Security Filters
10:40 - Companies table
11:02 - Users table
12:01 - Where to get more info (https://www.patreon.com/posts/security-filters-53384681)
12:57 - Wrap up