I need advice on what is the best way to structure my SAAS app/platform for companies.
I have a basic app for the users (Employees) and I’m working a platform for their employers which will allow managers to access the Employees’ data. I want the Employees/Users to own their own data and not have to create multiple User accounts and repopulate all of their personal data if they change jobs and move companies.
What I’ve done so far is to let each user own their data and have it assigned to their account.
Each ‘User’ Thing has a field that is linked to the ‘Company’ Thing. For people who do contracting, they may work for multiple companies and therefore this field is a list of companies.
When the company needs to search through employees, my RGs and lists are constrained based on the User’s “Company” field.
I’m concerned that this might be a bad way of doing it, in case a person moves on to a different job/company and they don’t want to link their account to the old Employer. If they disable the link, it would corrupt any historical data that was associated with the Company or created whilst employed there.
I’m now thinking that I should scrap that structure and create a third Thing called “Employees”. When a user is connected to a company, they can opt to share their data with the company. This would create a duplicate of their information in the “Employees” Thing. Any actions on the company side would be referenced to the “Employee” Thing and not the “User”.
If that user leaves the company, they can break the link to the company and any future updates to their personal account won’t update the “Employee” thing.
Think of it this way… you have a User-Company connection that’s currently set up as a list field within User. However you need each User-Company connection to have additional data about the nature of the connection – namely whether the User is still employed with that company. To have that data associated with each connection, you have 3 options…
As you’ve said, duplicate the User record and create a shadow copy (seems inefficient, but it’s an option)
Or, duplicate the “Company” field within “User” – have one of those list fields contain all Companies the User has been associated with, and the second field contain only current Companies.
Or, create a joining table that creates each Company-User connection, along with whatever data you need for that connection (and this allows you to add whatever data you want, like… still active, start date and end date, type of employment, whatever)
Which approach is “optimal” depends on what your app is designed to do, the nature of the search and display, and privacy rules.
One final point… if companies should only see data on their employees, make sure you set that up as a privacy rule, rather than a RG constraint. And also, note that option #3 can’t be used to create such a restriction since privacy rules don’t allow for a “search” of a datatype. So if you need #3, you also may need #1 or #2 for privacy.
Hi @ed727, thanks for replying to my post and for your advice, I really appreciate it.
With option 1, if the user decides to change data it in their app, it won’t affect the historical data in the company’s records. It might mean increasing the amount of data in the database, but instead of the admin account searching a list of Users, it’ll just be searching a list of Employees.
For option 2, this would preserve a link between the User and active Company, but if the employee changes some data in their profile, it might affect the data that a previous Company has on their records.
I’m not entirely sure how option 3 works with a joining table. I’m not familiar with this approach.
Are you suggesting creating a Thing for each link between a User and a Company.
Here are some possible user scenarios that explain my concerns.
“User A” is using the app for themselves.
They’re not linked to any company.
“User B” is a full time employee at “Company X”.
“User B” can use the app and their manager at “Company X” has access to their data.
“User C” is a contractor and works for “Company Y” and “Company Z”.
“User C” can decide to share certain information with either company.
“Company Y” may not have access to all the same data as “Company Z”.
“User D” previously worked at “Company X” but now works for “Company Z”
Their manager at “Company X” only has access to the historical information shared whilst they worked there.
Their new manager at “Company Z” has access to whatever information has been shared now.
Sounds like you have 2 things going on. One is the amount of data a user wants to share with a company. The second is preserving a snapshot of past data. On the first question, it’s a privacy rule issue. On the second, yes you’d need to have data “duplicated” in some way so the historical record stays put. Option 1 is a way to do that (and to cover the privacy issue as well).
