Single User, Multiple Accounts

In setting up the rules, I am trying to configure access to a collection when a single user belongs to multiple accounts. Examples often point to adding an array to user_data and check for the existence of a value…

"_accountId": {"$in": "%%user.custom_data.accountIds" }

Ideally, my custom_data object would be setup up as such…

accounts: [
{accountId:"aaa", role:"admin"},
{accountId:"bbb", role:"user", otherPermission:true}
]

I can’t figure our how to write the document permission that validates if the accountId in the document exists in the array of account values on the user custom_data object.

Am I going at this all wrong and is there a different way to handle this scenario? I am concerned that a user with an email address is added to Business A and then later starts working for Business B who also uses my app.

Thanks

Hi @Robert_Charest,

Can you please clarify whether you expect the same user to work for multiple accounts at the same time? Your example looks a bit ambiguous, in that respect.

That type of structure wouldn’t really fit for a match in a role: where and how are you looking to apply the rule? As there are special rule restrictions for Device Sync, you may have to limit the expressions if you plan to use Device Sync.

1 Like

@Paolo_Manna,

I am looking at building a time tracking system. Ideally I was looking for logins to be users personal email address. Company A and Company B both use my system (unrelated to each other). If an employee who works for Company A also gets a part time job with Company B, that one user would be attached to 2 different companies. I agree that Roles may not support this scenario.

What would be the correct way to setup logins to ensure there are no conflicts between the 2 companies?

Hi @Robert_Charest,

There isn’t a single solution to such setup: for example, there’s a lot of difference in setting up things if you use Device Sync (and which type of it - Partition-based or Flexible), and where the accountId is stored in your data model (to filter records properly, you should have it almost everywhere, except in EmbeddedObjects).

Overall, I’d suggest to experiment with multiple paths, trying to adapt to the Permission system, and, for example, the different subscriptions of Flexible Sync, to clarify what would be the easiest integration with your app: with this latest possibility, again as an example, the user would be identified as pertaining to multiple accounts at login, and it would have the possibility to filter the subscriptions related only to the account he’s willing to work on, as mixing the data from two accounts likely isn’t what you want.

1 Like