SAP BusinessObjects Planning and Consolidation drives consistency, transparency, and reliability in financial planning, management consolidation, business reporting, and operational activities. To use it optimally, it is important to set up a proper security model that allows users the access they need without the ability to access unnecessary data.

I’ll walk you through four security scenarios that show different levels of security within the dimension members when arranged in a hierarchy. First I’ll show you the important components of security in SAP BusinessObjects Planning and Consolidation.

Components of the SAP BusinessObjects Planning and Consolidation Security Model

The four components that are tightly integrated and make up the security model are:

1. Users: Users in SAP BusinessObjects Planning and Consolidation are simply the network users that reside on the active directory. You need to first set up users on the active directory domain and then add them to SAP BusinessObjects Planning and Consolidation security. Users designated as team leaders can save, delete, and modify reports and input schedules in the team folder.
2. Teams: Teams are similar to what were called user groups in SAP R/3. When you assign security to teams, the security works collectively on all the team members. Teams are not required to build a security model, but it is strongly recommended that you follow the team concept for easily manageable security. Conflicts can arise if security is directly applied to a user and also to the team in which the user is present; I’ll discuss this in detail throughout the article.
3. Task profiles: Security in SAP BusinessObjects Planning and Consolidation is governed by task profiles and member access profiles. The combination of these two profile types defines the way an individual can access and use different areas of SAP BusinessObjects Planning and Consolidation. Task profiles determine what a user or team can do in SAP BusinessObjects Planning and Consolidation. Unless assigned to a task profile, no user has access to any tasks.
4. Member access profiles: A member access profile determines access to a certain application and dimension member in which a user is provided read, write, or deny access to a secured member of a dimension. By default, dimensions that are not marked as secured are accessible by all users.

Security in SAP BusinessObjects Planning and Consolidation is maintained via the administration console. It is a wizard-based user interface. Users with a security task profile can easily add any user. They can assign a task profile, team, and member access profile using wizard functionality (Figure 1).

Figure 1

SAP BusinessObjects Planning and Consolidation administration console view with the Security node expanded

Security in SAP BusinessObjects Planning and Consolidation is based on task profiles and member access profiles. Security administrators assign profiles to users in SAP BusinessObjects Planning and Consolidation.

Task Profiles

Task profiles determine what type of activity or roles the user can perform (Figure 2). The system provides default task profiles with a predefined set of tasks assigned. Administrators need one or all of the predefined task profiles (can be cumulative):

1. System Admin: Can create, modify, or delete application sets and define security
2. Primary Admin: Can do all administrative activities except create, modify, or delete application sets
3. Secondary Admin: Can manage dimension members

Figure 2

Modify the task profile wizard

After selecting the functions, click the Next button (Figure 3). Besides the default profiles, you can select additional tasks. Tasks are grouped by interface. While the number of task profiles an administrator can assign to a user is not limited, assigning too many should be avoided because it becomes difficult to analyze a user’s cumulative authorizations. It is a best practice to assign profiles to a team rather than individuals. Profiles assigned that way work against all users in the team and are easier to manage.

Figure 3

Task profile wizard

Member Access Profiles

SAP BusinessObjects Planning and Consolidation does not have an object called a role, as SAP ERP Central Component (SAP ECC) and SAP NetWeaver Business Warehouse (SAP NetWeaver BW) do. Member access profiles determine access to the application and to the secured dimension members within the applications. You can consider the application an InfoProvider, while the dimension members are similar to InfoObjects in SAP NetWeaver BW. Users must be granted explicit authorizations to all secured dimensions to be able to use the application. You can provide security to the dimensions as read, write, or deny access to a given member within the dimension. In the member access profile, the access to the dimensions can be administrated. If you can write to a category, you can also read it. If you can’t read a category, you can’t write to it. By default, users have write access to all members of a dimension that are not marked as Secured.

You can modify member access profiles by accessing the Member Access Profiles node in the security console. This opens a wizard-based application (Figure 4).

Figure 4

Member access profile wizard

As with task profiles, there is no limit in assigning member access profiles to a user. You should follow team-based assignment for member access profile assignment. Security is applied collectively and the greatest access takes precedence. However, exceptions apply when a user has access to a dimension arranged within a hierarchy.

Hierarchies in Dimension Members

Conventionally, data is arranged in a hierarchy to represent organizational levels. You can arrange dimensions in SAP BusinessObjects Planning and Consolidation in a hierarchy as well. If there is no hierarchy in the dimension, the dimension is considered to be a flat dimension (Figure 5). If a hierarchy exists, the dimension is considered to be a hierarchical dimension (Figure 6). When the members of the dimension are arranged in a hierarchical order, the relationship between members is described with terms such as parent, child, and sibling. Security applies differently when the different members within a hierarchical level are provided different permissions.

Figure 5

Dimensions arranged in a table (flat dimensions)

Figure 6

Dimensions arranged in a hierarchy (hierarchical dimensions)

The overall rules that apply while securing dimension members within a hierarchy are:

• Rule 1: Within one member access profile, it is always possible to apply more specific security at a lower level in the hierarchy and the least privileged access takes precedence
• Rule 2: The greatest access wins when you are comparing across member access profiles

I’ll walk through specific scenarios by picking the sales entity hierarchy shown in Figure 6. I use a manufacturing company with sales units in different parts of United States, Europe, and Asia to walk through the hierarchical rules.

Scenario 1

Scenario 1 presents a situation in which there is one member access profile for the finance application called salesprofile1 (Figures 7 and 8). I assign read and write access to SalesEurope (the parent node) and assign read-only access to SalesItaly (the child node). As a result, I have write access to SalesSwitzer and read access to SalesItaly because you can apply a more specific security to the lower level within a member access profile (rule 1).

Figure 7

Security within hierarchical dimensions of salesprofile1

Figure 8

Access details for salesprofile1

Scenario 2

In scenario 2, there is still one member access profile within the finance application called salesprofile1 (Figures 9 and 10). I assign read and write access to SalesEurope and also assign read-only access to SalesEurope. As a result, I have read access to all members within SalesEurope, because the least privileged access inside one member access profile takes precedence. Deny access takes precedence over read, which takes precedence over write (rule 1).

Figure 9

Security within hierarchical dimensions of salesprofile1

Figure 10

Access details for salesprofile1

Let’s take the scenario in which there are two member access profiles for the same dimension within an application.

Scenario 3

In this scenario, there are two member access profiles for the finance application: salesprofile 1 (Figures 11 and 12) and salesprofile2 (Figures 13 and 14). In salesprofile1, I assign read and write access to SalesEurope within the finance application. In salesprofile2, I assign deny access to SalesEurope within the finance application. If both profiles are assigned to a user, consequently the user will have read and write access to all members within SalesEurope, because the greatest access across member access profiles takes precedence (rule 2). Write takes precedence over read, which takes precedence over deny.

Figure 11

Security within hierarchical dimensions of salesprofile1

Figure 12

Access details for salesprofile1

Figure 13

Security within hierarchical dimensions of salesprofile2

Figure 14

Access details for salesprofile2

Scenario 4

Scenario 4 also features both salesprofile1 (Figures 15 and 16) and salesprofile2 (Figures 17 and 18) for the finance application. In salesprofile1, I assign read and write access to SalesEurope and in salesprofile2, I assign read-only access to SalesItaly. If both profiles are assigned to a user, the user has read and write access for all members within SalesEurope because the greatest access across member access profiles takes precedence.

Figure 15

Security within hierarchical dimensions of salesprofile1

Figure 16

Access details for salesprofile1

Figure 17

Security within hierarchical dimensions of salesprofile2

Figure 18

Access details for salesprofile2

Viewing Security Reports

Reports come in handy while assessing security access to a user or profile. It is advisable to run reports after performing security changes for validation purposes. You can run security reports from the Admin Console and from SAP BusinessObjects Planning and Consolidation Web. You can execute reports based on user, team, member access profile, and task profile (Figure 19).

Figure 19

Action pane with security reports expanded

Here are a few tips for building an effective security model:

• Apply the simplest design possible
• Design security per team and avoid assigning profiles to users directly. If all users need different levels of access to the secured dimensions, then you should carefully follow a user access profile model to avoid granting unnecessary authorizations.
• Make extra effort while granting authorizations to dimensions arranged in a hierarchy