Multiple regions using same app
I know this has been covered briefly in some other threads here, but I have a specific question: I want to on-board another division in the company (does the same work as current division), with ...
Forum Discussion
OK, so I would not use groups at all, so I suggest that you erase that concept of groups out of your head.
I imagine that these records must have a division name or to identify the customers, for example 1 Division has many customers. So then you flow that division name or code down to all child records and limit access that way.
But if you do plan to have more divisions in future them there is a much cleaner way to go which will require just one Role called "Users allowed to see their own Division"
If you want to future proof your app (which I recommend), then here is a better concept.
You set up a table of users called Staff and set the key field of that table to be the userid field. Set up a relationship where 1 Division has many Users.
Then here is the magic,
Set up a relationship to say Customers where 1 Staff has many customers and for the reference field on the right side of the relationship, set up a field called [Current User] which is a formula user field with the formula of User(). That will calculate to the current User's userid.
Then lookup the User's Division.
Then set up a Permission Custom Rule that the Staff is allowed to see Customers where the [Current User - Division] = [Customer Division].
That way you only ever will need just 1 Role regardless of how many Divisions happen in the future. That is a way cleaner setup.
I imagine that these records must have a division name or to identify the customers, for example 1 Division has many customers. So then you flow that division name or code down to all child records and limit access that way.
But if you do plan to have more divisions in future them there is a much cleaner way to go which will require just one Role called "Users allowed to see their own Division"
If you want to future proof your app (which I recommend), then here is a better concept.
You set up a table of users called Staff and set the key field of that table to be the userid field. Set up a relationship where 1 Division has many Users.
Then here is the magic,
Set up a relationship to say Customers where 1 Staff has many customers and for the reference field on the right side of the relationship, set up a field called [Current User] which is a formula user field with the formula of User(). That will calculate to the current User's userid.
Then lookup the User's Division.
Then set up a Permission Custom Rule that the Staff is allowed to see Customers where the [Current User - Division] = [Customer Division].
That way you only ever will need just 1 Role regardless of how many Divisions happen in the future. That is a way cleaner setup.