It should be noted that although View Authorisations allow for a very granular way of restricting the objects that are displayed to users when they log into TE, the complexity and overhead of the role and user maintenance should be taken into account during the initial design phase.
It is also important to understand that assigning Authorisation Groups can have unintended consequences if not all objects within the object hierarchy are allocated to the same set of groups. For example, the View Authorisations configuration may give a user access to see a particular path, but not access to see Tasks (or Forms) that are part of a particular Project. This means the user will not be aware of all of the transports waiting for approval in a control point, but only those they have authorisation to see. They could therefore inadvertently only approve the transports they have authorisation to see, without knowing the full picture.
In general it is only recommended to use View Authorisations to separate out TE objects at the highest level, for example, to give separate views to the project delivery and production support teams, or to give separate views to two completely separate project teams using the same TE Domain Controller.
Post your comment on this topic.