Best practices for business roles
The following list provides guidelines to help you create and configure business roles, which are used to control access to the business data in a model site.
Note
Only members of the Data Administrator and Modeler roles can create a business role and configure permissions for the role. Only members of the User Administrator role can manage role membership and customize permissions for individual users.
Manage Planning Server roles in Planning Business Modeler only.
Use Planning Business Modeler to administer Planning Server business roles and permissions; do not directly apply SQL Server 2005 Analysis Services security from SQL Server Management Studio. Otherwise, conflicting permissions could jeopardize your data security.
If role permissions use a static list, use a static list when you define custom user permissions for the same dimension members.
The permissions that a user has for a data set may not exceed those of the business role to which the user belongs. They can be the same as the business role, or they can be more restrictive. Before you use a dynamic set to define user permissions for dimension members in a member set, make sure that the role permissions also use a dynamic set for the same dimension members.
Access to member set data is defined in the Change READ Permissions or Change WRITE Permissions dialog boxes by selecting individual dimension members as a static list. This can also be done by using the Add Descendants command to add a dynamic set. However, if you use a static list for the role and a dynamic set for the user permissions, you may give the user greater access to data than the role allows. This situation is more likely to occur if the Data Administrator (or Modeler) and the User Administrator are different users. When a role is configured in this manner, you will not receive any notification, and the role permissions may not be generated.
If you design business roles to manage security for specific dimensions, add a surrogate member to dimensions and enable Read access to the new member.
For permissions to be successfully generated when you enable access to a model for a business role, a role must have Read access to at least one member in every member set that the model contains. Otherwise, the role permissions for the model will not be generated, and you will not receive any notification. 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 allows 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 new member in the parent dimension and add the new member to the identified member sets.
Grant Read access to the new member in each identified member set.
Design business roles for users who require similar access to business data.
Before you create a role, identify the shared set of permissions for role members and then select the default permissions level that best matches the shared permissions. If you use this setting as the starting point for defining explicit permissions for data, you can minimize the modifications that you will have to make to the role definition. As a security best practice, use the most restrictive setting that applies.
For best Planning Business Modeler performance, try to minimize the need for custom user permissions when you define business roles. When you customize permissions for a user, you create a new Analysis Services role. The number of roles affects the time that is required to perform some tasks in Planning Business Modeler, such as deploying a model site.
Configure permissions for the business role before you enable access to specific models.
Before users who belong to the role can view any business data, access must be explicitly granted to each applicable model. After access has been granted, users can work with the data according to the permissions that are defined by the role. This feature prevents unintended access to data when you configure role permissions.
Be aware that roles can be used as user groups for assignment definitions.
Business roles can be added as user groups to process management tasks in an assignment. When a user is added to a role that is used in an assignment definition, the user is also added to applicable process management tasks.
If you add a user to a business role that is used as a contributor for assignments, you will receive a message that contains information about the assignments. If you also belong to the Data Administrator or Modeler role, you will be prompted to instantiate assignments for the new user.
Note
You must belong to the Data Administrator or Modeler role to create an assignment instance.
Similarly, if you remove a user from a business role that is used in an assignment or job definition, and you want to delete any instances that the user owns, you must purge them manually. For more information about assignments or jobs, see "Understand and work with assignments" or "Understand and Work with Jobs" in the product help.
Writeback requires write permissions in a business role and Contributor status in an assignment definition.
To enable writable regions in PerformancePoint Add-in for Excel, users must have Write permissions for at least one member in every dimension in the measure group that is used in the model. Instead of enabling Read access to actual business data, you can create a surrogate member in each dimension and enable Read access to the new member.
Before users who have been given Write access can write to the application database, data submission must be enabled in a corresponding assignment. For more information, see "Assign forms to a user for data submission" in the product help.
Other considerations
The following information may 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, any task that is currently being performed by the user, such as opening a report, may 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 enable users to select dimension members as parameters. Currency Translation and Consolidation jobs are examples. To select parameters and start the job from PerformancePoint Add-in for Excel, users must have Read access to the members that they want to use for the parameters. 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.
Note
Instead of enabling Read access to actual business data, you can create a surrogate member in each dimension and enable Read access to the new member.