Introduction

A role is a named set of system users and system groups with certain reporting and administrative permissions. Roles define each user's experience in the applications in terms of permissions, views, and accessibility. You assign permissions and accessibility to a role by adding special actions to the roles in SAP NetWeaver. For example, you can add the SSM_ViewInitiatives and SSM_CreateInitiative actions to a role to allow the users in the role to access the Initiatives tab and create initiatives.

When starting the application, the system evaluates each user based on their role. If you do not allow a role to use a certain feature of the application, that particular section is unavailable for the users in that role. For example, if a role is not given the permission to create initiatives, the Add Initiative link is unavailable in the Initiatives tab for the members of that role. If a role is not given access to the Home tab, that particular tab is not displayed for the users in that role.

You can set the following limitations on a role:

  • You can specify the strategy management application tabs available to the users in the role.

  • You can specify the administration application functions and strategy management application functions available to the users in the role.

  • You can specify which SAP NetWeaver UME users have this role.

  • You can specify the contexts available to a role using Start of the navigation pathContext Management Next navigation step Manage ContextsEnd of the navigation path in the administration application.

  • You must add all strategy management users to special reserved roles.

All the users in a role share the same functionality and access to the application. If you want an individual user to have a unique view, you must create a role with that user as the only member. A user can be a member of multiple roles.

You might need to create multiple roles that all have the same actions, where only the users vary. This is prevalent in scorecard hierarchies where different users access different contexts, but they all have the same set of permissions and accessibility. For example, you might have a Northeast context and a Southwest context, and the users of the contexts all have the ability to create scorecards, initiatives, and comments. Since you do not want Southwest users accessing the Northeast context and vice versa, you need to create two separate roles with the same actions to account for the different users.

Every strategy management user must be added to at least one role, even the strategy management administrator.

Process

Create roles, and add users and actions that designate permissions and accessibility.

For more information, see Actions for Roles and Creating a Role.

When you assign users to roles, keep in mind the model connections and contexts they are accessing. For example, say you assign user 1, user 2, and user 3 to a model connection. Then you assign user 1 to a role and you assign the role to a context that relies on that model connection. Only user 1 can access the context even though user 2 and user 3 can access the model connection.