SAP Learning Journey

Configuring Goal Plan Permissions

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Set up field and action permissions in a goal plan template and configure goal plan states

Permissions for Goal Management

Permissions for Goal Management are based upon the relationship between the person viewing the goal plan and the subject, the owner of the goal plan. The relationship between the subject and the viewer can also span across multiple roles in a company, which is referred to as line of sight.

Roles in Goal Management

The <role-name> element defines who receives permissions. The following is a list of the role names and their descriptions:

Role NameDescription
*Everyone
EEmployee
EMEmployee’s Manager
EMMEmployee’s Manager’s Manager
EM+Employee’s Manager, all the way up the hierarchy
EDEmployee’s Direct Report
EDDEmployee’s Direct Report’s Direct Report
ED+Employee’s Direct Report, all the way up the hierarchy
EMDEmployee’s Manager’s Direct Report (employee’s peers/co-workers)
EHEmployee’s HR Representative
FForm Reviewer (Goal access is restricted through a performance form only)
OPObjective Parent (Project team lead’s goal aligned up from team member’s goal)
OCObjective Child (Team member’s goal is aligned down from a team lead’s goal)
EPAll of the employee’s matrix managers
EXAn employee’s primary matrix manager

Field Permissions in XML

Goal fields need to have permissions in place to display in the goal plan.

Select the options below to start exploring the configuration code and the sub-elements.  

Field Permissions in XML

Best Practice: Remember, if every individual in a group of people has the same kind of permissions for the same fields, you can put all permissions within one element.

Field Permission Models

Select a Field Permission model to begin. 

Form Reviewer Role

The following permission area gives the Form Reviewer (F) the permission to read the milestones field.

Code snippet
<field-permission type="read">     <role-name><![CDATA[F]]></role-name>     <field refid="milestones"/>   </field-permission>Expand

Watch this video to learn more about the Form Reviewer Role.

Action Permissions

The <permission> element describes general goal access permissions, and is generally referred to as an action permission. While field permissions allow visibility and editing of fields, action permissions grant the ability to perform specific actions on a goal plan, such as adding, deleting, or cascading goals. As with field permissions, action permissions are based on the relationship between the form viewer and the form subject.

Currently, you add action permissions to the goal plan through XML. Action permissions are easily set up using the code snippet below. A number of action permissions types apply to a goal plan template.

Code snippet
<permission for="delete"> <description><![CDATA[Only the employee and the direct manager may delete goals.]]></description> <role-name><![CDATA[E]]></role-name> <role-name><![CDATA[EM]]></role-name> </permission>Expand

Select each of the Action Permissions Types below to learn more.

Configure Field and Action Permissions

Business Example

A client has asked you to configure the Goal Plan permissions for their instance. Configure the permissions as specified here. You will be starting with the Action Permissions and continue with the Field Permissions, to follow the order of elements in the XML template.

Learn how to configure field and action permissions in the Goal Plan XML template.

ExerciseStart Exercise

Configure Action Permissions

Steps

  1. Configure the private-access permissions. Ensure that the permissions allow the following:

    • Employee (E) and Employee’s Manager (EM) should be able to access private goals.

    1. Update the XML using the following code as a guide:

      Code snippet
      <permission for="private-access"> <description><![CDATA[Only the employee and employee’s manager can access private goals]]> </description> <role-name><![CDATA[E]]></role-name> <role-name><![CDATA[EM]]></role-name> </permission>Expand

    2. Save and validate your XML, but do not upload to the instance.

  2. Configure create permissions. Ensure that the permissions allow the following:

    • Employee (E), Employee’s Manager, and Employee’s Direct Reports (ED) can create goals on the employee’s goal plan.

    1. Update the XML using the following code as a guide:

      Code snippet
      <permission for="create"> <description><![CDATA[Only the employee, employee’s manager, and employee’s direct reports can create goals on the employee’s goals plan]]> </description> <role-name><![CDATA[E]]></role-name> <role-name><![CDATA[EM]]></role-name> <role-name><![CDATA[ED]]></role-name> </permission>Expand

    2. Save and validate your XML, but do not upload to the instance.

  3. Configure the Delete permissions. Ensure that the permissions allow the following:

    • Only the employee can delete goals on their plan.

    1. Update the XML using the following code as a guide:

      Code snippet
      <permission for="delete"> <description><![CDATA[Only the employee can delete goals on his or her plan]]> </description> <role-name><![CDATA[E]]></role-name> </permission>Expand

    2. Save and validate your XML, but do not upload to the instance.

  4. Configure the move permissions. Ensure that the permissions allow the following:

    • Only the employee can move goals on their plan.

    1. Update the XML using the following code as a guide:

      Code snippet
      <permission for="move"> <description><![CDATA[Only the employee can move or indent goals on his or her plan]]> </description> <role-name><![CDATA[E]]></role-name> </permission>Expand

    2. Save and validate your XML, but do not upload to the instance.

  5. Do not edit the other action permissions.

    Configure Field Permissions

  6. Configure the following requirements:

    • Employee (E) and Employee’s Manager (EM) should be able to edit the state field, and all other managers above the employee’s manager (EM+) should only be able to view this field.

    • Everyone else in the organization should not be able to see or edit this field.

    Hint
    Remember that the default permission of a goal plan XML template is "none," meaning no one can view (read) or edit (write) to any fields without a specific permission.

    1. Update the XML using the following solution as a guide:

      Code snippet
      <field-permission type="read"> <description><![CDATA[Managers all the users can view this field]]></description> <role-name><![CDATA[EM+]]></role-name> <field refid="state"/> </field-permission> <field-permission type="write"> <description><![CDATA[Employee and employee’s manager can view and edit this field]]></description> <role-name><![CDATA[E]]></role-name> <role-name><![CDATA[EM]]></role-name> <field refid="state"/> </field-permission>Expand

    2. Save and validate your XML, but do not upload to the instance.

  7. Configure the Tasks (targets) permissions. Ensure that the permissions allow the following:

    • No one should see the field, except for the Employee (E) and Employee’s Manager (EM)

    • Employee and Employee's Manager should be able to edit the field

    1. Update the XML using the following solution as a guide:

      Code snippet
      <field-permission type="write"> <description><![CDATA[The employee and employee's manager can edit tasks field]]></description> <role-name><![CDATA[E]]></role-name> <role-name><![CDATA[EM]]></role-name> <field refid="targets"/> </field-permission>Expand

    2. Save and validate your XML, but do not upload to the instance.

  8. Configure the permissions for the Custom Fields you created previously. Ensure that the permissions allow the following:

    • No one should see the fields, except the Employee (E) and Employee's Manager (EM).

    • Employee should be able to edit the fields, and Employee's Manager will be able to view the fields.

    1. Update the XML using the following solution as a guide:

      Code snippet
      <field-permission type="read"> <description><![CDATA[The employee’s manager can view custom fields]]></description> <role-name><![CDATA[EM]]></role-name> <field refid="INSERT YOUR CUSTOM FIELD ID HERE"/> </field-permission>Expand
      Code snippet
      <field-permission type="write"> <description><![CDATA[The employee can edit custom fields]]></description> <role-name><![CDATA[E]]></role-name> <field refid=" INSERT YOUR CUSTOM FIELD ID HERE"/> </field-permission>Expand

    2. Save and validate your XML, but do not upload to the instance.

Goal Plan States

Goal Plan States provide the ability to have more than one set of permissions. The difference between states can be subtle or drastic depending on the customer’s needs.

Watch the video to learn more about Goal Plan States.

Real World Scenario for Goal Plan States

A customer sees the Goal Management module and feels that they need to have a signature after goals are set. Additionally, the customer may request to ‘lock down’ or ‘approve’ the goals after they have been acknowledged. 

The consultant explains that there are no signatures or workflows used in Goal Management and that this functionality only exists in Performance Management. 

Configuration Solutions:

  • Goal Plan States can be configured to record approval/acknowledgement and potentially remove permissions that replicate the ‘lock down’ of goals. This feature allows components of the Goal to be locked once an authorized user locks the plan (E, EM, and so on.) 
  • The permission to change states is configured by relationship role (not RBP). The different states do not have to vary drastically, permissions can be anywhere from identical, to opposite, or anything in between.

Use case:

When the goal plan is unlocked (not approved), the E role should be able to create, delete, move, cascade-align, cascade-push, and share goals. The E should also have write permissions to all fields when adding/editing a goal. The figure Unlocked Goal Plan illustrates the unlocked (unapproved) goal plan.

When the goal plan is locked (approved), the E should not be able to create, delete, move, or cascade goals. The E should not be able to edit any fields anymore; the goal fields should be read only to the employee. The figure Locked Goal Plan illustrates the locked (approved) goal plan.

Goal Plan States Configuration

The goal-plan-states element is used to configure the goal plan states. It is placed in the XML after the last field-definition element and before the plan-layout element. 

The goal-plan-states element contains the sub-element goal-plan-state which must be added twice, the first one with id=unlockedand the second one with the id=locked. 

The goal-plan-stateselement groups all the action and all the field permissions into an unlocked and locked state. This allows you to control the action and field permissions prior to a goal plan being approved, and after the plan is approved. You cannot have permissions outside of the goal-plan-states element. 

Simply copy-paste the existing permissions within the goal plan state code and close off the goal plan state code with end tags. Look at the opening tags of the code to see what the code should be closed with.

Caution
Be sure to practice version control!

Obj-Plan-States Code Explained

Select the buttons to see the element code and learn more.

Note
The goal plan states code should be placed after the last </field-definition>, and before the <plan-layout>. 
Note
When using Goal Plan States, you may not want to include some action permissions for a more restrictive state. This is fine, but when uploading the Goal Plan XML template in Provisioning, you may notice red warning messages if certain action permissions are not present. You can still proceed and ignore the warning messages, if that is the configuration requirement.

Configure Goal Plan States

Business Example

For this exercise, you will configure the Goal Plan XML template to wrap up action and field permissions into the goal plan states of locked and unlocked.

Learn how to set up Goal Plan States with different field and action permissions in the Goal Plan XML template.

ExerciseStart Exercise

Steps

  1. Configure goal plan states in the XML template.

    1. In your XML file, wrap up all existing action and field permissions in the "unlocked" state and place after the last </field-definition> tag.

    2. Use the sample code below to guide this exercise:

      Code snippet
      <obj-plan-states> <obj-plan-state id="unlocked" default="true"> <state-label>Not Approved</state-label> <action-label lang="en_US">Un-Approve</action-label> <permission for="change-state"> <description><![CDATA[EM can change to locked state.]]></description> <target-state><![CDATA[locked]]></target-state> <role-name><![CDATA[EM]]></role-name> </permission> </obj-plan-state>Expand
      Note
      Code Samples: Sample code must be broken into small sections to include the entire section. Copy-paste each section in order in your XML data model for the section to function correctly. For this exercise, the code for #1B should be placed in XML before #1D. If you were to reverse this order, you would be placing the start- and end-tags of goal plan states in the wrong order and will receive an XML validation error.

    3. Create the "locked state" permissions after the ending tag of </obj-plan-state> and before <plan-layout>

    4. In the "locked" state, grant the following permissions:

    • No one can create, delete, cascade, or move goals.

    • The employee and direct manager should still be able to share private goals and un-share public goals, as well as seeing private goals.

    • All the other action permissions should not be accessible to anyone.

    • The employees should be able to view all fields, and edit the targets, % complete, comments, and the status of the goal.

    • The employee’s direct manager should be able to view all fields and edit the comments field.

    • All managers above the employee in the organizational hierarchy should be able to view goal fields.

    Note
    The start-tag <obj-plan-states> must be closed by the end-tag </obj-plan-states>

    Example

    Use the sample code below to guide this exercise:

    Code snippet
    <obj-plan-state id="locked"> <state-label>Approved</state-label> <action-label lang="en_US">Approve</action-label> <permission for="change-state"> <description><![CDATA[EM can change to unlocked state.]]></description> <target-state><![CDATA[unlocked]]></target-state> <role-name><![CDATA[EM]]></role-name> </permission> </obj-plan-state> </obj-plan-states>Expand

  2. Test the goal plan states in the instance.

    1. Validate in the XML editor, save-as a new version, and import the XML template from Provisioning, and select Import/Export/Update Objective Plan Template.

    2. Log into the instance, proxy as Manny Manager and navigate to the goal plan. Make sure the [Your Initials] Goal Plan is selected.

    3. Verify you see Not Approved as the goal plan status.

    4. Create a goal and cascade it to Edward Employee

    5. Use the directory in the goal plan and navigate to Edward's goal plan. Verify you see the link to Approve the plan.

    6. Click Approve.

    7. From the name menu, select Proxy Now and proxy into Edward Employee (whose goal plan was approved).

    8. Navigate to the goal plan. Make sure the [Your Initials] Goal Plan is selected.

    9. As the end user, try to edit a goal and to see which fields are read-only and which fields are editable. Look at the tool bar along the upper-right hand corner of the goal plan — are you able to add a new goal or cascade goals?

    10. If you are not seeing the expected behavior during testing, continue to edit the XML file until you are satisfied with the final results.

  3. You have successfully created goal plan states and performed some testing from an end-user perspective.

Log in to track your progress & complete quizzes