If role permissions use a static list of dimension members, use a static list when you define custom user permissions for those dimension members.

You can specify access to member set data in two different ways:

By using the Change READ Permissions, or the Change WRITE Permissions dialog box in Planning Business Modeler. This method creates a static list of dimension members.

By using the ppscmd Add Descendants function from a command line. This method creates a dynamic set of dimension members.

In some cases, these two methods can specify data access permissions that conflict with each other. For example, if you use a static list of members for role permissions, and a dynamic set of members for individual user permissions, you might specify more data access to an individual user than the user role allows. Because the permissions that a user has for a data set might not exceed those of the business role to which the user belongs, a conflict occurs. If you configure a role in this manner, PerformancePoint Planning Server will not generate the permissions for the business role because it will detect the conflict . Furthermore, you will not receive an error message or notification. .

If you design business roles to manage security for specific dimensions, add a surrogate member to each dimension and enable Read access to the surrogate member.

When you enable access to a model for a business role, you must make sure that the role has Read access to at least one member in every member set that the model contains. Otherwise, PerformancePoint Planning Server will not generate role permissions for the model. Users who belong to the role will not be able to access any data that the model contains.

You are more likely to encounter this behavior if you design roles to manage security for specific dimensions instead of designing roles for specific models. If you prefer to design roles to manage the security for dimensions, use the following procedure. It enables role permissions to be generated for the model without allowing unnecessary access to actual business data.

Identify the member sets in the model that will not be granted Read permissions by the role.

Create a surrogate member in the parent dimension, and add the surrogate member to the identified member sets.

Grant Read access to the surrogate member in each identified member set.

Design business roles for users who require similar access to business data

Before you create a business user role, identify the shared set of permissions for role members and then configure the default permissionsthat best match the shared permissions. If you use the default permission configuration as the starting point for defining explicit permissions for data, you can minimize the changes that you will have to make to the role definition. As a security best practice, use the most restrictive configuration that applies.

Be aware that a business roles can be selected as Contributors in assignment definitions.

You can select a business role as a Contributor for process management tasks such as a job or an assignment. In this situation, the business role behaves like a user group. Then, when you add a user to the role, the user is automatically to the list of Contributors for the task.

If you remove a user from a business role that is used in an assignment or job definition, and then want to delete any job instances or assignment instances that the user owns, you must purge the instances manually. For more information about assignments or jobs, see the "Schedule a job" section of Schedule a job task.

Submitting data to the application database requires Write permissions in a business role, and Contributor status in an assignment definition.

Users who enter data in PerformancePoint Add-in for Excel must have Write permissions for at least one member in every dimension in the measure group that is used in the model. Before a user who has Write access can submit changes to the application database, data submission must be enabled for that user in a corresponding assignment. For more information, see Assign forms to a user for data submission in Planning Business Modeler.

Other considerations

The following information might be useful when you configure roles or implement your security model:

Members of the Data Administrator and Modeler roles have unrestricted access to all business data in the model site, even if they belong to a business role that has restricted settings.

When you remove a user from a role, and the user is currently performing a task such as opening a report, the task might succeed. This is because permissions are verified before a task is started. The user will be prevented from performing subsequent tasks.

Some types of jobs, such as Currency Translation and Consolidation, enable users to select dimension members as parameters. To select parameters and start the job from PerformancePoint Add-in for Excel, users in a business user role must have Read access to the members that they want to use for the parameters.

Note: This behavior does not apply to users who belong to the Data Administrator or Modeler role because they have unrestricted access to all business data within their scope.