Planning security policies

Before you begin configuring security policies, determine the security needs of your organization and then plan your security strategy.

First, determine how many security roles and project roles you need. Then, determine whether you need to create multiple security policies or whether you can simply modify the Global policy to meet your needs:

If all the business units in your organization follow the same rules, or, you can implement the appropriate differences in access through a combination of project and security roles, it makes sense to implement one security policy – a modified Global policy. You can add as many security roles as necessary to the Global policy.

If there are many functional groups in your organization that require very different types of access, leave the Global policy in its default state and add new security policies for each group of users.

At any given time, a user can have a project role, an object role and a security role. It is best practice to assign a user one security role only from a single security policy. Therefore, if you have users who multi-task in such a way that they need more than one security role in addition to their project and object roles, it is recommended that you create additional security policies and assign that user one role from each of the appropriate security policies.

As a best practice, try to implement the smallest number of security policies possible. Within a single security policy you can configure different permissions for each object type and for each marketing object template based on security roles. Additionally, for each project template you can configure different security role and project role permissions for each tab (custom and default) for both the projects and the requests.

When you set up permissions for the roles, remember that the individual permission settings are granular. For example, if you want users in a particular role to be able to edit the Summary tab of a project, you must grant that role both Edit and View permissions. If you forget to select View permissions, users in that role will never see the Summary tab so their permission to edit it is useless. In another example, it would not make sense to grant permission to post messages without also granting permission to read them.