Assigning Roles and Permissions in Goal Management

Objective

After completing this lesson, you will be able to describe the roles involved in the goal management process and the relationship between permissions and goals

Line of Sight in Goal Management

SAP SuccessFactors uses data from the User Data File (UDF) to determine the reporting relationships between employees. These reporting relationships are used to determine who can see whose goals in SAP SuccessFactors. These relationships are also used to permission goal plan actions such as adding, deleting, and cascading goals.

Line of Sight is defined as goal visibility up, down and across the organization. Visibility is permissioned by role for each client’s goal plan based on the business needs and culture of the company.

Different companies may have entirely different visibility permission models. Some may restrict visibility of goals to only go down the management hierarchy while others may be configured for full visibility up, down and across all levels.

Note

The concept of line of sight of goals throughout an organization is a key element in Goal Management.

Roles in Goal Management

Roles are established based on the relationship between the viewer of the goal plan and the subject of the goal plan, as determined by the employee data in the instance.

Roles are most easily understood by breaking the role codes into their separate parts, as follows:

  • E (short for Employee): This is often the first part of the role code, and indicates that we are looking at the relationship of the person to the employee. The actions we are describing will therefore impact the employee.
  • Subsequent letters: This could be the manager, direct report, HR representative, etc. The person described in this role code is granted or denied permission to impact the goals of the employee, based upon the configurations.

Commonly Used Roles

The following table, Commonly Used Roles, shows some commonly used roles along with their descriptions.

Role NameDescription
*Everyone
EEmployee
EMEmployee’s Manager
EMMEmployee’s Manager’s Manager
EM+Employee’s Manager, all the way up the hierarchy
EMDEmployee’s Manager Direct Report
EDEmployee's Direct Report
EXEmployee's Matrix Manager

Note

Roles currently supported in Goal Management and typical actions mapped for each role can be found in the Roles in Goal Plans section, in the implementation guide:

Roles in Goal Plans | SAP Help Portal

The Matrix Manager Role

The matrix manager is a secondary manager, one who can have many of the same privileges and permissions of a regular manager. The role can be manually managed in the profile or it can be automatically loaded in the user data file (discussed later in this module).

A common use case is for organizations that allow for dotted line or dual reporting relationships. A primary manager must be designated, but the matrix manager can have very similar permissions.

For example, the matrix manager can be permissioned to create and edit goals for an employee.  The route map can be configured to send review forms from an employee to their matrix manager, before the regular manager gives final approval.

Permissions

Permissions within Performance and Goals are relational – the permissions are based upon the relationship between the viewer of the form and the subject of the form.

Permission Options

When discussing permission options with customers, the individual requirements of the company are an important factor to consider. The way the actions and visibility are permissioned is based upon the company’s culture. For example, wide-spread visibility across levels may be desired within an open culture. Whereas, in a more closely guarded culture, a more closely-held visibility can be configured.

Consider the customer’s industry when making recommendations. For example, a financial institution will likely be used to more privacy, whereas a high-tech company will likely be more open. Check with the customer to make sure that goal visibility is adhering to any applicable state, local or federal law, industry standard, or applicable regulation.

The following permission types are used:

  • Permissions that you control as the system administrator such as access to tools and tool-specific settings.

  • Permissions that are embedded within the XML code template of an object such as form section visibility and goal visibility.

Action Permissions

The following actions are configurable in a Goal Plan and relevant to the latest version of Goal Management.

  • Private access

    Define who has permission to see private goals, that is, goals that are not shared or made public.

  • Cascade-pull

    Define who has permission to cascade goals from another user's goal plan. Cascade-pull can be configured and permissioned per role. For example, ED and EM+ have the permission to cascade-pull. Remember it will not work unless you have the ability to read other people's goals.

  • Cascade-push

    Define who has permission to cascade goals to another user. If no roles are listed, the Cascade to Others button does not appear when you are looking at your own goal plan.

  • Create

    Define who can insert a goal in a user's goal plan.

  • Delete

    Define who can delete a goal from a user's goal plan. We do not recommend that you list no roles for this permission. In addition, group goals will always allow the user who created the goal to delete the goal for themselves.

  • Share

    Define who can mark goals as shared (Public) or unshared (Private) in a user's goal plan.

Log in to track your progress & complete quizzes