+1 from me.
Relatable bases, to summarise content from a master/complete/project base into a specific collaborators base showing assigned tasks (distilling collaborators tasks from many individual bases to a singular base) is a must for our business.
Use case: each base is a construction call forward sheet containing every task to complete a project (500 plus tasks). Tasks are assigned to multiple collaborators/companies or to company employees.
The database owner and some of its users need to see the complete base for each project, all task view, to assign, comment and adjust tasks, keep the singular base/project updated. Other employees only need see task assigned to them or their division (sales/admin/contracts/estimating/scheduling/site). Sharing filtered or grouped views could achieve the filtering of internal company information/viewing by internal company collaborators.
A collaborator has tasks on multiple bases/jobs, but does not need to see all the tasks in an individual base ) they get lost/confused/just don’t need to see everything.
Consequently, linking each base/project to an individual collaborator’s “summary base” that shows only those tasks they have been assigned from each “complete base” is essential in our workflow.
This way, each collaborator is provided a link/access to one “summary” base, that they can share to all of their employees, seeing, commenting and completing only those tasks assigned to them from multiple “complete/project” bases.
A many to one and one to many type database relationship.
Sort of like what we could do with MS Access SQL databases (when MS Access was all we had)