|
    Good practices to observe when planning permissions are:
| • | Because roles and then sites override all other permission configurations, reserve the ability to modify role-based permissions for power users who understand the permissions feature. Typically you should not change the Everyone and Administrator roles after initial configuration. For more information, see section Understanding Role-based Permissions. |
| • | Configure the higher permission level, Sites, to allow broader access. When permissions are set to Deny at higher levels in the Permissions hierarchy, permissions configured specifically for Allow access at a lower level will not provide the intended access to documents. As a rule of thumb, allow higher level permissions to remain <not set>, or set them to Allow so that it is possible to implement Allow or Deny for permissions such as Browse, Read, Delete and so on at lower levels. For the illustration of the Permissions hierarchy, see section Permissions. |
| • | When planning all permissions, create a diagram or chart of who will have access to what. Not only will this help you organize the permissions for your own review and that of others, but when finalized, charted permissions help determine who can do what after implementation. |
 IMPORTANT Permissions that are <not set> provide access to documents differently depending on administrative rights. Administrators have full access to documents in areas that are <not set>. Everyone else has no access to the permissions that are <not set>. To make a user an administrator, mark the Method Developer option for that user in the User Management application.
|