Hi everyone,
This looks like it may solve for the problem, as per this simple diagram:
The major change in architectural approach from the original post is to move away from the 'Group' containers but deal with the individual staff records in one table (parent/1) and then the related activity records in a child/many table. This should allow the Access Team to be set up once per Staff member in the parent/1 table, enabling the Access Team logic to cascade to the corresponding activities in the child/many table. The Group Leaders can then be added to the Access Team appropriate to the Staff record.
The users expect to have about 100 staff records in this solution.
Although initial testing looks very promising, before full development takes place, having never used these Access Teams before I am appealing to the community for any comments on:
1. Performance.
1a. In this solution, each Access Team will have the same Security Role, since only Read is required. Is it OK to have ~100 Access Teams in a single solution (one per Staff record)?
1b. If I use this technique in the future, what about Access Teams with different security roles? Is it correct only 4 Access Team templates are permitted per table/entity?
2. Any tips on administering the Access Teams? I am proposing to do this via a Power Automate Flow that will set the Group Team membership on the basis of a 'friendly' drop down that the admin users will select (Group Membership) on the Staff record, which in turn will fire a Flow and add the relevant personnel to the Access Team. Any improvements or observations on this?
3. Best Practice. Any tips on best practice configurations or anything to avoid?
4. Any other "gotchas" or concerns with this proposed implementation?
Thank you very much!
