You can use flags to create very specific paths of access to documents. The system supports the use of up to 63 flags.
The following examples have two flags, U1 and U2, and two users, User1 and User2:
| • | You can set User1 to have full access, that is, the ability to browse, read, add, delete, or add a new revision of documents, using flag U1 and be denied all access using flag U2. |
| • | User2 can have the opposite access, that is, full permissions using flag U2 and denied all access using flag U1. Depending on the flag assigned to each document in the system, User1 and User2 could be able to view and process a completely different set of documents otherwise assigned to the same project. |
This can be an efficient and secure way to set up permissions. To avoid situations in which documents are not handled in a timely fashion, such as when User1 is out of the office, planning is important when adding flags. For example, plan which users have access to the documents using the flags, so that someone is always on hand to process the documents in a timely fashion.
Other good practices that you can observe when planning flags are:
| • | Restricting the access to the Add Flag permission to power users only, who consider an overall effect on the system. These users can then add and/or assign flags to documents and workflows. |
| • | When planning permissions, including flags, it can be helpful if you create a diagram or chart of who will have access to what (see a sample diagram in section A Diagram for Permission Flow). Not only will this help you organize the permissions for your review and that of others, but when finalized, charted permissions can help you determine who can perform different tasks long after implementation. |
| • | Planning flags with the overall effect on the system in mind so that you do not need to delete many flags later. Deleting flags after they are put into production can cause unexpected gaps in access and/or security because when you delete a flag, it is automatically removed from all documents to which it was attached. |
| • | Configuring the higher system levels of permissions, such as sites, with future flag configuration in mind. When permissions are set to Deny at higher levels in the Permissions hierarchy, then flags, which are at a lower level may not provide the intended access to documents. Configure higher level permissions to be <not set> or Allowed in order for flags to be useful regarding the same permissions such as Browse, Read, Delete, and so on. To view a diagram of the Permissions hierarchy, see section Permissions. |
IMPORTANT Permissions that are <not set> provide access to documents differently depending on administrative rights. Administrators have full access to documents for permissions that are <not set> at the site/project/file type/flag levels. All other users have no access in the other areas that are <not set>. To make a user an administrator, mark Method Developer for that user in the User Management application.