I would say that, ideally, using the lower granular field as reduction field will provide more flexibility, so in this case, the
"project" would be the reduction field, instead of project manager or region.
However, if your data model has thousands of rows and is exposed to thousands of people, the section access table could grow too big to be maintainable or performing.
In this case, think then on creating profiles or groups of people (you can use a concatenated field at the beginning to make sure you get what you expect):
Simplifying, let's say data looks like this
Project_Manager, Region, Key
John, EU, John|EU
John, US, John|US
Mark, US, Mark|US
Now let's say I have to see Mark's projects (all US) plus those of John in the US as well. Then section access would look like
Person_Name, Key
Miguel, Mark|US
Miguel, John|US
This could be further simplified using a numeric key for each profile.
Circling back, if using project number as the key in the section access table is possible and does not make the table big, use it instead, you will not have to care about any exceptions or combinations: each user will have a line in the section access table for each project he or she is allowed to see.
.png "Miguel_Angel_Baeyens"){kind=avatar}
.png "Former Employee"){kind=icon}
