Document Actions
3.
Site Structure - Example 1
Up one level
Root
DMS Area (Area)
Client ABC (Entity)
Tax (Section) (Harry - Preparer; Sarah - Reader)
Engagement tax2001 (Engagement)
Engagement tax2002 (Engagement) (Sarah - Preparer)
Internal-Audits (Section)
Engagement Internal-Audit 2001 (Engagement)
Engagement Internal-Audit 2002 (Engagement)
Client DEF (Entity)
Tax (Section)
Engagement tax2003 (Engagement)
Example 1 shows a straightforward organization, where the site has a single Area, in which are placed the Entities, each representing one client of the firm. There are no sub-Entities; the Entities contain only Sections, which contain Engagements. The main organizational tool used here is Sections. In this case the firm has used two Sections, one for Tax, which appears in both Entities, and one for Internal Audits, which appears only in one Entity. A realistic setup may look very much like this, only with many Entities.
The local roles are shown here in red. A realistic site structure would likely have many more local roles assignments than are shown here. These are provided simply as an example of how roles are inherited by users at lower levels of the tree.
Harry has been given the Preparer Role for the Tax Section within Client ABC. This will give him that role for all Engagements below that point, which in this example are the two Engagements: Engagement tax2001 and Engagement tax2002
Sarah has been given the local Reader role for Tax Section within Client ABC, and the local Preparer role for Engagement tax2002. This means, on Engagement tax2001 she has Reader permissions, and on Engagement tax2002 has both Reader and Preparer permissions. In this example, Reader permissions are strictly a subset of Preparer permissions, so it’s equivalent to having only Reader permissions on Engagement tax2001 and Preparer permissions on Engagement tax2002.
In this example, both Harry and Sarah have the Preparer role on Engagement tax2002.