Projects can be sensitive, and we don't always want every user of a system to be able to see or explore them. Examples of this might be feasibility studies for business change that may or may not happen, projects that have confidentiality clauses with customers or suppliers, or other security concerns. In this guide we'll look at several ways in which a project visiblity can be limited to selected users.
One option is to apply protective marking (for subscriptions that support this). The security marking applied will restrict visibility of the project only to users whose clearance includes that protective marking. Protective marking applies not only to projects, but also many other objects such as companies, products and skills. Users without appropriate clearance will not be able to view the object, or even see it in lists.
Another mechanism is to set the project Eyes-Only. When set, the project will only be visible to members of that project. By default, protective security markings, and eyes-only settings are inherited by created sub-projects.
Where system access is granted to customers or suppliers, a more restrictive approach may be taken. User permissions include a flag to view other user projects. An example user permission set called stranger is defined in the demo data set, and has this flag unset. When applied to users, this has the effect that all projects appear to have the Eyes-Only property enabled. In other words those users can only see projects to which they are a member.
The approach taken can be a mix of these features. If project visibilty is not usually an issue, then the occasional exception can be handled by setting Eyes-Only, whereas using security clearances and protective markings may impose a needless administration overhead. Choose a sensible balance between securiy and useability based on your risk appetite.