Configuring Goal Plan Permissions

Objectives

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

The <field-permission> element defines who sees and edits fields in the goal plan. Permissions are based on the relationships between the employees in the organization. Templates contain base permissions needed to test and work with the goal plan during configuration. 

The system reads permissions in the order in which they are listed in the XML (from top to bottom). The last applicable permission is the one used in the instance. 

Note
In Goal Management, the default setting for permissions is none (no permissions). If permissions are not specifically set up, no one can read or write to any field in the goal plan. You must have the correct permissions to fields to view or edit fields. Permissions can only be set at the XML template, not in Manage Templates.

Field permissions differ greatly by company culture, and you can configure them to the customer’s specifications. There are three options for field permissions: Read, Write, and None.

Field Permission Types

Permission TypeResult
NoneThe user cannot see or edit the field at all.
ReadThe user can see but not edit the field.
WriteThe user can see and edit the field. Write permission implies Read permission, so they do not have to both be set up.

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 Permissions Example (1)

The following permission area gives the Employee (E), the Employee’s Managers all the way up the reporting chain (EM+), the Employee’s HR Representative (EH), the Employee’s Direct Reports (ED), and the Form Reviewer (F) the permission to read the name, metric, weight, start, due, state, done and milestones fields.

Field Permissions Example 2

The following permission area gives the Employee (E) and the Employee’s Manager (EM) the permission to edit ("write") the category, name, metric, weight, start, due, state, done, and milestones fields.

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

Action Permission Types

PermissionGrants the ability to:
"private-access"See private/unshared goals.
"cascade-pull"Pull another user’s goals on to your goal plan.
"cascade-push"Push one’s own objectives on to another user’s plan.
"create"Create goals in a goal plan.
"delete"Delete goals from a goal plan.
"share"Share/unshare (make public/private) goals.
"create-row"Create a row in a field type="table".
"delete-row"Delete a row in a field type="table".
"move-row"Move a row up or down in a field type="table".
"change-state"Change the state (status) of the current goal.
Note
Any action permissions not listed here are only relevant for the legacy GMv12 version.

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 existing <private-access> configuration 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. Validate the XML and continue to the next step.

  2. Update the existing <create> permissions configuration. 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. Validate your XML and continue to the next step.

  3. Update the existing <delete> permissions configuration. Ensure that the permissions allow the following:

    • Only the employee can delete goals on their plan.

    1. Use 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. Validate your XML and save, but do not upload to the instance yet. Do not edit the other action permissions.

  4. Configure the following requirements:

    Configure Field Permissions

    • Employee (E) and Employee’s Manager (EM) should be able to edit the comments 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 existing <field-permission> configuration, using the following solution as a guide:

      Code snippet
      <field-permission type="read">
             <description><![CDATA[Everyone may read all fields for everyone.]]></description>
              <role-name><![CDATA[*]]></role-name>
              <field refid="name"/>
              <field refid="metric"/>
              <field refid="weight"/>
              <field refid="start"/>
              <field refid="due"/>
              <field refid="done"/>
              <field refid="state"/>
              <field refid="milestones"/>
             </field-permission>
             <field-permission type="read">
             <description><![CDATA[Managers all the way up the hierarchy may read these fields.]]></description>
              <role-name><![CDATA[EM+]]></role-name>
              <field refid="comments"/>
             </field-permission>
             <field-permission type="write">
             <description><![CDATA[Employee and manager may edit these fields]]></description>
              <role-name><![CDATA[E]]></role-name>
              <role-name><![CDATA[EM]]></role-name>
              <field refid="name"/>
              <field refid="metric"/>
              <field refid="weight"/>
              <field refid="start"/>
              <field refid="due"/>
              <field refid="done"/>
              <field refid="state"/>
              <field refid="milestones"/>
              <field refid="comments"/>
             </field-permission>
      Expand

    2. Validate your XML and continue to the next step.

  5. Configure the permissions for the milestones table field. Ensure that the permissions allow the following:

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

    1. Update the existing <field-permission type="read"> configuration, granted to everyone <role-name><![CDATA[*]]></role-name>. You need to remove the existing <field refid="milestones"/> to ensure this field is not visible, to anyone, except for the Employee (E) and Employee's Manager (EM). You can use this solution as a guide:

      Code snippet
      <field-permission type="read">
             <description><![CDATA[Everyone may read all fields for everyone.]]></description>
              <role-name><![CDATA[*]]></role-name>
              <field refid="name"/>
              <field refid="metric"/>
              <field refid="weight"/>
              <field refid="start"/>
              <field refid="due"/>
              <field refid="done"/>
              <field refid="state"/>
             </field-permission> 
             <field-permission type="write">
             <description><![CDATA[Employee and manager may edit these fields]]></description>
              <role-name><![CDATA[E]]></role-name>
              <role-name><![CDATA[EM]]></role-name>
              <field refid="name"/>
              <field refid="metric"/>
              <field refid="weight"/>
              <field refid="start"/>
              <field refid="due"/>
              <field refid="done"/>
              <field refid="state"/>
              <field refid="milestones"/>
             </field-permission>
      Expand

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

  6. Set the permissions for the custom field you created in the previous exercise. Ensure that the permissions allow the following:

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

    • Employee (E) and Employee's Manager (EM) should be able to edit this field.

    1. Remove <field refid="discussion"> from the read permissions granted to everyone. The write permissions granted to Employee (E) and Employee's Manager (EM) should look like this example:

      Code snippet
      <field-permission type="write">
             <description><![CDATA[Employee and manager may edit these fields]]></description>
              <role-name><![CDATA[E]]></role-name>
              <role-name><![CDATA[EM]]></role-name>
              <field refid="name"/>
              <field refid="metric"/>
              <field refid="weight"/>
              <field refid="start"/>
              <field refid="due"/>
              <field refid="done"/>
              <field refid="state"/>
              <field refid="milestones"/>
              <field refid="discussed"/>
             </field-permission>
      Expand

    2. Save and validate your XML..

  7. Import the updated Goal Plan XML template in Provisioning.

    1. Navigate to Provisioning → Import/Update/Export Objective Plan Template .

    2. Select Choose File and locate your XML file.

    3. Select Upload.

    4. Verify you can display the confirmation message Goal Template was updated successfully.

  8. Test the permission configuration in the instance.

    1. Proxy as an Employee.

    2. Navigate to your goal plan using the quick action Manage My Goals, available in the Home page.

    3. Select one of your goals and choose Edit Goal to make some changes.

    4. Change the Goal Visibility to Private. Save changes.

    5. Verify you can still see the goal in your Goal Plan.

    6. Verify you can Create and Delete goals.

    7. Select Create Goal and choose Create from Scratch.

    8. Verify you can edit the Status, add Milestones and edit your custom field. Save changes.

    9. Proxy as a Manager and navigate to the Employee's goal plan.

    10. Verify you can create but not delete goals, and the private goal is also visible.

    11. The goal that the employee has created should be editable.

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, 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-states element 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

Below follows the code of the element and its sub-elements along with explanations: 

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 or cascade.

    • 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 milestones, % 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