Multiple regions using same app

Yes, if you plan to have a small number of companies, this is the way to go.

For the Roles which are going to be restricted, they would be named like Staff Admin Group 1

You will not be duplicating the Roles which have global access to both groups.

If you do have special users who need to see both groups, then they can be put into both groups, do not make a third group for them, just put them in Roles in two groups.

so if i'm understanding correctly, 

1) I have to create 3 new roles each time I add a new "division"? then

2) I have to put those 3 roles into their own group, then 

3) In table access properties, I set the view/modify drop down to "Groups records"?


Since I already have a lot of existing data (for our current division), how do I know which group this existing data will fall under?  this begs another question:

If the "special admin" who has access to both groups - creates a record, which group will that record be seen under?

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 like your idea, however there may be an issue. 

First:  I don't have a field/table at the moment that identifies the division to which a record belongs.

Secondly: my app has many tables which suggests that your method would require the relationship for each table? also how would this apply to child tables etc?

Well, assuming that there was a "top level" table like customer which did have a division, then you can make a formula checkbox field called
[User is allowed to see this record?] and then just look that up all the way down the chain to children and grand children and great grandchildren. 

Then the Role Permissions would just have a Custom Rule for each restricted table such that the user can see where [User is allowed to see this record?] is checked.

As for this: First:  I don't have a field/table at the moment that identifies the division to which a record belongs. 

I don't know the nature of your app, but my suggestion is to code the records in some top level table in the app by Division!