Configuring Development Goal Plan Using XML

Objectives

After completing this lesson, you will be able to:

  • Modify the General Settings for a Development Plan Template using XML
  • Configure standard and custom fields in a Development Plan template in XML
  • Set up Action and Field permissions in a Development Plan template using XML
  • Edit the Plan Layout of a Development Plan template using XML
  • Configure Development Plan Template switches
  • Configure the Competencies field

XML General Settings

XML Overview

The Development Plan XML gives you full configuration control, whereas Manage Templates in Admin Center gives you limited options. For example, do you want to have one competency per development goal, or multiple competencies per development goal? This can only be configured through the XML. All items within Admin Center are also configurable within the XML. For example, the plan Start Date uses the XML element <obj-plan-start>. Some elements are easy to correlate while others can be challenging.

The General Settings elements and attributes are located at the top of the XML.

XML Attributes

Many of the General Settings attributes cannot be edited in the Admin Center and must be changed via XML. This section reviews some of those General Settings attributes that must be changed via XML.

General Settings Attributes

OptionValid ValuesDescription
Spellchk

true

[Spell Check] button appears next to the [Save Changes] and [Cancel] buttons underneath the goal being created/edited.

false*

Disables spell check for all goals.

new-obj-share-status-public

true

New goals will be created as a shared/public goal.

false*

Goals are created as private goals.

alerts-viewdefault

on

Sets the View Options checkbox to automatically display on-plan alerts to new users. The alerts can indicate who created or edited a goal and when if the creator is different than the goal plan owner. Alerts can be cleared.

off

On-plan alerts will not be displayed unless the user checks the View Options Alerts checkbox.

pager-max-objs-per-page

number

Sets the number of goals displayed per page on the goal plan. If set to 0, all goals will be displayed on one page.

display-alignment-format

names

Displays the name of the owner of the goal.

goals

Displays the name of the goal.

use-text-for-privacy

true

Text is displayed next to goal to indicate whether goal is public or private.

 false*

Icons are displayed next to goal to indicate whether goal is public or private.

max-goals

number

Sets the maximum number of goals that should be in a goal plan. (Note: this will not show on the goal plan unless the pager-max-objs-per-page is set to greater than 0.)

min-goals

number

Sets the maximum number of goals that should be in a goal plan. (Note: this will not show on the goal plan unless the pager-max-objs-per-page is set to greater than 0.)

max-weight

number

Sets the maximum total weight of all goals in a goal plan.

min-weight

number

Sets the minimum total weight of all goals in a goal plan.

max-weight-per-obj

number

Sets the maximum weight of each objective in a goal plan.

min-weight-per-obj

number

Sets the minimum weight of each objective in a goal plan.

Modify General Settings – XML

To edit the Development Goal Plan Template in XML, the template must first be exported from Provisioning. This is done in the Managing Plan Template area, under Import/Update/Export Development Plan Templates. Once the template has been exported, it can be opened in an XML editor to make changes.

To learn how to edit template XML files, watch this video:

General Settings allow you to activate different features within your development plan template:

Example 1: Newly created goals are currently defaulting to "public," but the customer wants them to default to "private." Change the new-obj-share-status-public attribute as follows:

  • from: new-obj-share-status-public="true"
  • to: new-obj-share-status-public="false"

Example 2: To change the public/private indicator from an icon to text, change the use­-text-for-privacy attribute as follows:

  • from: use-text-for-privacy="false"
  • to: use-text-for-privacy="true"
Note
Be sure to leave the obj-plan-id as is. If this is changed, an entirely new Development Plan will be uploaded. Development plan IDs are in the following range: 2000-2999.

The figure illustrates the before view for both the XML view and the Development Plan view of Examples 1 and 2 outlined in the previous section.

The goal privacy indicator is an icon and defaults to a light color that means it is set to public.

Note
Private goals can only be viewed by the roles permissioned to see private goals. When using proxy, you will not see another user's private goals. Privacy is controlled by XML permissions and can be set to allow any permissioned role to see private goals.
Note
Be sure to leave the obj-plan-id as is. If this is changed, an entirely new Development Plan will be uploaded. Development plan IDs are in the following range: 2000-2999.

Modify General Settings - Additional XML Settings

Text Replacement allows you to replace standard text with custom text within the XML. Do not confuse this with the Text Replacement tool in Admin Center. All text replacement options can be found in the DTD objective-template_4_0.dtd and are added via the text-replacement element.

Common XML Text Replacement Options

Attribute

What Is It?

Instructions

Instructional text at the top of the goal plan. Note that the "I" at the beginning of the attribute is capitalized.

add-goal-to-plan

Create a New Goal button in goal plan.

category

Category label, displayed in the Goal edit box.

copy-from-my-other-goal-plan

Replaces the text on the Copy From Other Goal Plan button.

The figure below illustrates the before view for both the XML code and the Development Plan view showing examples of XML-based text replacements.

Note
The instructions, as seen previously, can be edited via the Admin Center, but they can also be changed in XML. Instructions are the only text replacement option that can be completed through Admin Center.

Modify Development Plan General Settings in XML

To learn how to complete this exercise, watch this video:

Practice modifying Development Plan General Settings in XML:

As a consultant, you are asked to modify the Development Plan general settings in XML.

Steps

  1. Export the latest version of your Development Plan XML from Provisioning.

    1. Navigate to Provisioning and select Company ID. Then navigate to Managing Plan Template, select Import/ Update/Export Development Plan Templates, export your template, and open it in a preferred XML Editor.

    2. Validate the file against the DTD (objective-template_4_0.dtd) provided with your Course files.

    3. Save the file to a new name and version, following the naming convention from previous exercises.

    Note
    Make sure you’re exporting your Development Plan Template, and not the template of another learner. Follow the line of the template with your ID number and name in the template name.
  2. In the Development Plan Template ensure new goals will default to public.

    1. Change the new-obj-share-status-public attribute within the XML from new-obj-share-status-public="false" to new-obj-share­ status-public="true"

  3. In the Development Plan Template ensure the public/private indicator is text and not an icon.

    1. Change the use-text­ for-privacy attribute from use-text-for-privacy="false" to use-text-for-privacy="true"

  4. In the Development Plan Template add a new sentence: Add your THR95 development goals here. to your Instructions (Welcome) text.

    1. Begin by locating <text-replacement for="Instructions">. Enter the sentence Add your THR95 development goals here. between the first and second sentences of the instructions.

  5. In the Development Plan Template modify the text in American English (en_US) for adding a new goal to Add New THR95 Goal.

    1. After the "Instructions" text replacement add the code below. Do NOT copy the first and last lines of code because those are used to identify the location where this sample code is placed.

      Code snippet
      
      </text-replacement>
      
      <text-replacement for="add-goal-to-plan">
        <text><![CDATA[Add a New THR95 Goal]]></text>
       </text-replacement>
      
      <category id="Goals">
      
      Expand
  6. Validate the file against the DTD (objective-template_4_0.dtd) provided with your Course files. Save the file as a new version.

    1. [See the video for troubleshooting steps for validating the file.]

  7. Import the new file to Provisioning.

    1. Go to your company instance and then under Managing Plan Template go to Import/Update/Export Development Plan Templates.

    2. Test your instance by logging in as the CDPAdmin user you set up (for example, Chris Adams).

    3. Verify your changes to the development plan in the front end. Check the Introduction section to make sure your new text appears. Then click the + Add Goal button and verify the new text appears for the add goal option.

    4. Create a new goal.

        • Go to Development
        • Add a new goal
        • Goal Name: Sample Goal
        • Goal Description: Sample Goal Description
        • Status: On Track
        • Save and close
    5. Verify under the Visibility column you see the text that reads: Public.

Configuration of Categories in XML

Categories are used to organize Development Goals, and they are set up using the category element. Within the category element, there must be a category ID and a category name.

The category ID appears in reports and can only be configured in the XML. The category name is what appears in the instance.

It is best practice to have the category ID and category name be as similar as possible. In addition, special characters should not be used in the category IDs. When a category is added from Admin Center, the system assigns an ID with the name "categoryX" where X is a numeric value. This ID should be edited in the XML to match the category name.

Note

Do not set the category ID to a number. Numbers are not intuitive when the customer is running reports. The category ID is case and space sensitive; using spaces is not recommended.

The <default-category> element

The <default-category> has the following considerations: 

  • There is only one <default-category> that can be configured as such in the XML template.
  • The <default-category> always comes after the last </category> defined in the XML template. This order is enforced by the DTD objective-template_4_0.dtd
  • The <default-category> is optional and more frequently used in Goal Plans than Development Plans. 

Here’s an example of the <default-category> XML:

Code snippet

<category id="Goals">
<category-name>Current Goals</category-name>
</category>
<category id="ArchivedGoals">
<category-name>Archived Goals</category-name>
</category>
<default-category id="Default">
<category-name>Select Current or Archived Goals Category</category-name>
</default-category>
Expand

Configuration of Standard Fields in XML

Standard Fields

As discussed in previous sections, both Standard and Custom fields are available to be added to a Development Plan. Although adding fields is generally completed in Admin Center, both Standard and Custom fields can be added through XML.

Adding new fields through provisioning using XML follows a three-step process, because a couple of the steps that were performed automatically for you in Admin Center now need to be done manually in XML:

  1. Define the field.
  2. Permission the field.
  3. Add the field to the Layout.

The XML for a standard field follows a repeatable pattern. Here’s an example of the name field that we can break down to see the various attributes:

Code snippet
<field-definition id="name" type="textarea" required="true" detail="false" viewdefault="on" showlabel="false" default-calc-type="step" field-show-coaching-advisor="true" cascade-update="push-down">
<field-label>Goal</field-label>
<field-description>Goal</field-description>
</field-definition>
Expand

The Development Goal Field configuration interaction provides additional details on each step in adding a new field through XML.

Select the buttons to learn more about Goal Fields configuration.

Goal Fields Configuration

Select the buttons to learn more about Field Definition elements.

Field Definition Elements

Certain attributes are required for any field definition. For example, the id attribute and the type attribute must be defined or the file will fail to validate against the DTD. Some attributes are not required, such as detail or showlabel.

There is also one required child element: field-label . All other child elements are optional.

Select the buttons to learn more about Standard Fields.

Standard Fields

Additionally, the table Standard Fields lists details about commonly used Development Plan Standard fields. These can all be added through Admin Center.

Standard Fields

Field ID

Type

Typical Usage/Characteristics

name

text

textarea

enum

The name of the goal; sometimes relabeled as goal description. This is the only field that is required to be defined in a goal plan.

desc

text

textarea

enum

Use for a detailed goal description if the name being used is short.

metric

text

textarea

enum

Used to measure how a goal will be measured; success criteria.

start

date

The start date of the goal. This is auto-populated with the date defined in obj-plan-due, but can be changed (if permissioned).

due

date

The end/due date of the goal. This is auto-populated with the date defined in obj-plan-due, but can be changed (if permissioned).

state

enum

text*

textarea*

The status of the goal; where the user is in the process. Typically presented as a drop-down list of values with colors to represent the status. Used in dashboard reports. Limited to 128 characters.

purpose

enum

text*

textarea*

The purpose of the goal. Typically presented as a drop-down list of values with colors to represent the purpose of the goal.

competency

competencies

Pulls in competencies based upon job code, library, category, or other specified characteristic. More details about competencies are provided in a separate topic.

Field Types

The table Field Types shows a list of available field types. It is important to remember that Standard fields are limited to a predetermined set of field types. Custom fields typically use text, textarea, enum, date, or percent.

Field Types

Type

Description

bool

True or false value.

comment

Configures the layout and permissions for public comments.

competencies

Configures the layout and permissions for competency links.

date

Date (MM/DD/YYYY).

enum

Enumerated type (shown as a drop-down list).

number

A number value.

percent

Percentage (rounded to the next whole number; have % appended).

rating

The rating of the goal; used for configuring a metric-lookup-table.

table

A table of data; fields have a specific set of allowed table-columns.

text

One line of text.

textarea

Multiple lines of text.

link

Hyperlink.

While all of these field types are available in XML, not all of them are available when adding fields through Manage Templates in Admin Center.

Other Standard Fields

Similar to Goal Management, other standard fields can be configured on the Development Plan. These are standard fields that cannot be added through Manage Templates in Admin Center, they need to be added through the XML. For example, if the customer wants the user to add milestones to each of their goals. The milestones field is a non-Admin Center Standard field.

Here are some other standard fields:

Other Standard Fields

Field ID

Type

Label (these can be modified)

Typical Usage/Characteristics

weight

enum

percent

text*

textarea*

Weight

The weight of the goal in the goal plan. The value in the field will also be used to auto-populate the objective weight in the PM form. If configured as enum, the value (not the label) is used in the form. If configured as text, the text value entered is used verbatim.

milestones

table

Milestones

A table of individual milestones towards achieving the goal.

tasks

table

Tasks

A table of individual tasks supporting the goal.

targets

table

Sub-goals

A table of individual targets towards achieving the goal.

XML-only Attributes

To make changes to attributes not available in Admin Center, locate the desired element, and make the change. For example, if you do not want the field to be automatically turned on in the Display area of the Development Plan, change the viewdefault code.

This change will force the end user to click the checkbox in the Display area of the Development Plan in order to see it on the plan.

The table describes additional <field-definition> attributes and can be saved for reference.

AttributeValid ValuesDefault ValueDescription
requiredtrue, falsefalseIf true, a red asterisk (*) appears next to the field and the user is required to complete the field. If false, the user can leave the field blank.
detailtrue, falsefalseCurrently, this attribute is not used; leave as default.
viewdefaulton, offonControls the default display view of the field on the Development Plan. If this attribute is set to "off", users will have to select the field in the Display Options in order to see it on the plan layout.
showlabeltrue, falsefalseField labels are not displayed by default when viewing goals in the goal plan, but they are always displayed in the goal edit window. If the goal plan column headings or tasks/targets/milestones column headings are adequate in representing the fields displayed, field labels may not need to be displayed. This will help reduce vertical scrolling when viewing goals in the plan. For this configuration, set showlabel="false". However, consider displaying field labels for fields that are not in the first row of the goal plan, especially if the fields in those rows are not the table fields (tasks/targets/milestones). For this configuration set showlabel="true".
reportablefieldXn/aDetermines which custom fields are available in reporting. XML reads as reportable="fieldX" where "fieldX" is field1 — field20. For example, if the customer wanted a custom field to be reportable, the XML would read reportable="field1" (or other available number 1–20). Up to 20 fields can be designated as reportable across an entire company. Refer to the objective-template DTD for more details. This attribute can ONLY be configured in the XML and it is not available in Manage Templates.
field-show-coaching-advisortrue, falsefalseIf true, the link to the Coaching Advisor will display above the field. Only applies to field type "textarea".
spellchktrue, falsefalseIf true, the link for Spell Check will display above the field. Only applies to field type "textarea".
trigger-completiontruen/aThis attribute applies to the State/Status field only, and will appear as true only when a value is selected for the Trigger Completion option. It will be added to the value that has been selected for the Trigger Completion.
cascade-updatepush-down, regular rolluppush-downOnly applicable for group goals. NOT used in Career Development Planning.

*These permissions are used in Goal Plans in the Performance and Goal Management Module.

The words used for the attributes in the XML cannot be used as the field-definition IDs. Doing so would create issues.

For example, if we configure a custom field with field-definition id="type" type="enum", because the word type is a field attribute, when adding a development goal on the mobile application, this custom field displays as a free text box and not an enum field.

There are additional field options, which can be found in the Career Development Planning Implementation Guide: Goal Plan Template Elements and Attributes

Configuration of Custom Fields in XML

Custom Fields

We have already seen that custom fields can be added through Admin Center. They can also be added through XML. For custom fields, the Field ID and Field Type are determined by the customer. It is important to decide if custom fields need to be reportable.

Field ID

Type

Typical Usage/Characteristics

custom field

text

textarea

enum

date

percent

You have the option to define and report on custom fields that are defined in your goal plan. These are goal field types that are not listed in the DTD. Because they are not listed in the DTD, you can make up your own field ID to reflect what information will be gathered and stored by the field.

Add Custom Fields via XML

The figure below shows adding the custom field link AFTER the standard purpose field.

Note
The reportable attribute must be included for reportability on several reports, including Ad hoc reports.
Note
Remember, adding custom fields can be completed in Admin Center, but reportability is an XML-only attribute. The above could be an example of first adding in Admin Center and then including the reportable attribute in XML.

Configure Development Plan Fields in XML

To learn how to complete this exercise, watch this video:

Practice configuring Development Plan Fields in XML:

As a consultant, you are asked to configure the field settings in XML for your development plan.

Steps

  1. Export the latest version of your Development Plan XML from Provisioning.

    1. Navigate to Provisioning and select your Company ID. Navigate to Managing Plan Template and select Import/Update/Export Development Plan Templates.

    2. Export the latest version of your Development Plan template using the red arrow on the right side of the screen.

      Note
      Make sure you’re exporting your Development Plan template, and not the template of another learner. Follow the line of the template with your ID number and name in the template name.
    3. Open the template in your preferred XML Editor and save the file to a new name and version, following the naming convention from previous exercises.

  2. For each field make sure the labels are being shown by default.

    1. Locate each of the fields on the plan. For each field, ensure that you have the following configuration for all the fields: showlabel = "true".

  3. After the last field definition code, add the metric field definition. Copy the code below:

    Code snippet
    <field-definition id="metric" type="textarea" required="false" detail="false" viewdefault="on" showlabel="true" field-show-coaching-advisor="false">
        <field-label>Measure of Success</field-label>
        <field-label lang="de_DE">Erfolgsmaß</field-label>
        <field-description>Measure of Success</field-description>
        <field-description lang="de_DE">Erfolgsmaß</field-description>
    </field-definition>
    Expand
    1. Sample code is also provided for the metric field in the configuration file titled Code For Metric 2023.xml.

  4. Make the custom field you added through Admin Center reportable.

    1. Add the attribute reportable to the field definitions similar to the following:

      Code snippet
      <field-definition id="link" type="link" required="false" detail="false" viewdefault="off" showlabel="true" field-show-coaching-advisor="false" cascade-update="push-down" reportable="field1"><field-label>Help Link</field-label>
      <field-description>Help Link</field-description>
      </field-definition> 
      Expand
    2. Validate the file against the provided DTD (objective-template_4_0.dtd).

    3. Save your changes. Since you renamed the file earlier in the exercise, you do not need to rename it again.

  5. Import the new file to Provisioning.

    1. Navigate to ProvisioningImport/Update/Export Development Plan Templates.

  6. Test the changes.

    1. Log in as your CDPAdmin user and add a new goal. Although the metric field was defined in the XML, you did not permission the field or add it to the plan layout yet, so it will not be visible.

    2. Use Action Search to navigate to Manage Templates. Review your newly uploaded THR95 Development Plan template. Confirm that the metric field does appear in the template right below the purpose field.

Setting up Action and Field Permissions

Action And Field Permissions

In addition to configuring fields on the Development Plan, the customer needs to decide which business roles are able to work with the goals and fields. Development Plan permissions are different than Role-Based Permissions, but both are used to grant access to users.

Role-Based Permissions allow access to the Development Goal Plan. Once users have access to the goal plan, all other permissions are governed by the XML plan permissions.

Development Plan Permissions Overview

When fields are added in Admin Center, permissions for that field are automatically added to all existing permission blocks. This may not be the desired behavior, so permissions must be further edited via XML.

When fields are deleted from Admin Center, the field and its permissions are removed.

When fields are added through XML, permissions need to be added to all existing permission blocks manually. The same is true when fields are deleted through XML.

The next sections discuss the process of editing two kinds of Development Plan permissions: Action permissions and Field permissions.

Action Permissions

Action permissions define the roles that have the ability to perform specific actions on a goal plan, such as adding or viewing private goals.

Note
Private access is an important and sometimes misunderstood concept. Privacy can mean different things to different people based on business context. So it is important to point out that private access can be granted to any role including the everyone (*) role. Typical configurations include access only to the employee (E) or access to the employee and employee's manager (EM). Private access configuration should be clearly communicated with employees to avoid any issues.

Select the buttons to learn more about Action Permission.

Action Permission

The above figure shows an example of the XML before permissions are modified (that is, no HR Rep) and after permissions are modified (that is, the HR Rep is included). In the after example, the HR Rep permission is represented by the EH role that is highlighted in yellow.

Modify Action Permissions - XML

The table All Permissions displays a list of possible action permissions.

Permission

Grants the Ability to:

"private-access"

See private/unshared goals.

"cascade-pull"

Pull another user’s goals on to one’s own plan. Not used in CDP.

"cascade-push"

Push one’s own objectives on to another user’s plan. Not used in CDP.

"cascade-align"

Align one’s own goals with another user’s goals. Not used in CDP.

"create"

Create goals in a goal plan.

"delete"

Delete goals from a goal plan.

"delete-group-goal"

Delete a group goal from a goal plan.

"move"

Move goals within the same category on the goal plan.

"share"

Share/unshared (make public/private) goals.

Many customers like to keep development private. In this case, the "share" permission would need to be completely removed and goals should default to private in the General Settings area of the XML.

"unalign-parent"

Unalign a parent (original) goal. Not used in CDP.

"unalign-child"

Unalign a child (cascaded/aligned) goal. Not used in CDP.

"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."

"bizx-request-update"

Ask a goal owner for a status update; Goal Execution only.

"change-state"

Change the state (status) of the current goal.

"import-goal"

Import the user’s goals from another goal plan.

"export-goal"

Export the user’s goals to another goal plan.

Field Permissions

In order for fields to be visible or editable, Field permissions must be put in place. This is an XML-only configuration.

Possible field permissions are as follows:

  • Read - the user with Read permission can see, but not edit the field. 
  • Write - the user with Write permission can see and edit the field. Write permission implies Read permission, so they do not have to both be set up.
  • None - the user cannot see (or edit) the field at all.
Note

None is the default permission (users have no permissions until Read or Write are assigned), so normally a None permission would not be necessary.

Field permissions exist in blocks that are read by the system from top to bottom, so a lower Read permission block could potentially override a higher Write permission block. Best practice is to place Read permissions above Write permissions in the code list.

Select the buttons to learn more about Field permissions in XML.

Field Permissions in XML

The above figure shows the before and after XML when a field permission is changed. The before examples shows two permission blocks (highlighted in yellow). In this example, no one can edit "link" because there is no permission for "link". The after example shows three permission blocks (highlighted in yellow). In this example, the roles E and EM can edit "competency" and the role EH can edit "link".

Field Permissions - Note on Roles

Select the buttons to learn more about the Line of Sight Hierarchy.

Line of Sight Hierarchy

Roles for Development Plan XML Permissions are the same as in Goal Management and the non-RBP data model.

Role Name

Description

*

Everyone

E

Employee

EM

Employee’s Manager

EMM

Employee’s Manager’s Manager

EM+

Employee’s Manager, all the way up the hierarchy

ED

Employee’s Direct Report

EDD

Employee’s Direct Report’s Direct Report

ED+

Employee’s Direct Report, all the way down the hierarchy

EMD

Employee’s Manager’s Direct Report (employee’s peers/co-workers)

EH

Employee’s HR Representative

F

Form Reviewer (Goal access is restricted through a performance form only)

OP

Objective Parent (e.g., a project team lead’s goal that is aligned up from a team member’s goal)

OC

Objective Child (e.g., a team member’s goal that is aligned down from a team lead’s goal)

EP

All of the employee’s matrix managers

EX

An employee’s primary matrix manager

For a complete list of roles, see the following KBA: https://launchpad.support.sap.com/#/notes/2087940

Edit Permissions in XML

To learn how to complete this exercise, watch this video:

Practice editing permissions in XML:

As a consultant, you are asked to edit permissions for your Development Plan.

Steps

  1. Export the latest version of your Development Plan XML from Provisioning and rename it following the naming convention from previous exercises.

    1. Navigate to ProvisioningImport/Update/Export Development Plan Templates.

    Note
    Make sure you’re exporting your Development Plan template, and not the template of another learner. Follow the line of the template with your ID number and name in the template name.
  2. Give Goal Creation permissions to the Second Level Manager.

    1. This comes from the create permission in the Action permissions within the XML.

    2. Sample code is below in step 3, and also available in the configuration file named Code For Action Permissions 2023.xml to help you set all action permissions.

    Note
    You can review a list of roles in the following KBA: https://launchpad.support.sap.com/#/notes/2087940
  3. Update the permission description to reflect your permission changes. The completed Create permissions will appear as follows:

    Code snippet
    <permission for="create">
        <description>
            <![CDATA[The following roles may create goals in a user's plan.]]>
        </description>
        <role-name><![CDATA[E]]></role-name>
        <role-name><![CDATA[EM]]></role-name>
        <role-name><![CDATA[EMM]]></role-name>
    </permission>
    
    Expand
  4. Make all fields readable by all roles (*). The completed Read field permissions code will appear as follows:

    Code snippet
    <field-permission type="read">
        <description><![CDATA[The following roles may read the following fields]]></description>
        <role-name><![CDATA[*]]></role-name>
        <field refid="name"/>
        <field refid="desc"/>
        <field refid="metric"/>
        <field refid="due"/>
        <field refid="start"/>
        <field refid="state"/>
        <field refid="competency"/>
        <field refid="purpose"/>
        <field refid="link"/>
    </field-permission>
    
    Expand
    1. Sample code is also available in the configuration file named Code For Field Permissions 2023.xml to help you set all field permissions.

  5. Make the Custom Link field writeable by Employee's Managers by adding the role EM.

    1. Add a new Read permission for the Link field.

      Code snippet
      <field-permission type="write">
          <description><![CDATA[The following roles may write to the following fields]]></description>
          <role-name><![CDATA[EM]]></role-name>
          <field refid="link"/>
      </field-permission>
      
      Expand
  6. Make all fields editable by the Employee.

    1. Make sure all fields are listed under the Write permission. The completed Write field permissions will appear as follows:

      Code snippet
      <field-permission type="write">
          <description><![CDATA[The following roles may write to the following fields]]></description>
          <role-name><![CDATA[E]]></role-name>
          <field refid="name"/>
          <field refid="desc"/>
          <field refid="metric"/>
          <field refid="due"/>
          <field refid="start"/>
          <field refid="state"/>
          <field refid="competency"/>
          <field refid="purpose"/>
          <field refid="link"/>
      </field-permission>
      
      Expand
    Note
    Notice how the Read permissions are listed first and the Write permissions are listed next. Remember, order counts with permissions.
  7. Save the file.

  8. Validate the file against the provided DTD (objective-template_4_0.dtd) but do not upload it yet.

    Note
    There is no need to upload this file into Provisioning yet, because many of the fields in your Development Plan need to be added to the plan layout. This will be done in the next exercise.

Editing the Plan Layout

Plan Layout Overview

By now, you know how to configure fields and how to permission fields. You also know how to add goals to the Development Plan. But where are the goals and the fields? Why are they not visible?

The next piece in working with Development Plan fields is to decide which fields should be placed on the plan layout. The plan layout arranges fields in the order they should be viewable on the Development Plan in the instance.

Edit the Plan Layout - XML

The first step in editing the plan layout is to export the Development Plan XML to an XML editor and analyze existing behavior.

The following bullets explain what we see in the code in the above figure: 

  • Four fields are configured in the layout: "name," "metric," "due," and "state."
  • The column weight determines how wide the column is on the layout. The "name" field will be the widest. If columns have a weight of 0, the field only takes up as much space as it requires .
    Note
    Note that columns with a weight of 0 will not show up in the performance form at all.
  • Columns will populate left to right in the order defined from top to bottom.
    Note
    You can have more than one field in a column.

When fields are added in Admin Center, they are automatically placed on the plan layout. XML-added fields are not automatically placed in the plan layout like they are in Admin Center.

The figure above shows the before and after XML where a customer has requested the following:

  • The "link" field to be located in the first column, under the "name" field.
  • The "desc" field to be located in the second column, under the "metric" field.
  • The "state" and "due" fields to be equally weighted.

The figure above shows the effect of the XML code change in the instance.

Edit the Plan Layout

To learn how to complete this exercise, watch this video:

Practice editing the Plan Layout:

As a consultant, you are asked to edit your Development Plan layout.

Steps

  1. Do NOT export the latest version of your Development Plan XML from Provisioning. Reopen the latest version of your Development Plan in a preferred XML editor.

    Note
    Since you did not upload your changes from the previous exercise, if you were to download the latest version of your Development Plan from Provisioning, you would overwrite the changes you made in the previous exercise. When making iterative changes to XML, typically you will initially download the XML file from Provisioning only once. Then you will save successive changes locally and upload each new version to Provisioning.
  2. Confirm the following fields are on the layout, as seen in the sample code below:

    1. Locate the <plan-layout> section of the XML. It is near the end of the file.

    2. The first column should have the Goal Name field.

    3. The second column should have the Goal Description field. The completed Plan Layout will appear as follows:

      Code snippet
      <plan-layout>
          <column weight="10.0">
          <field refid="name"/>
          </column>
          <column weight="25.0">
          <field refid="desc"/>
          </column>
          <column weight="25.0">
          <field refid="metric"/>
          </column>
          <column>
          <field refid="purpose"/>
          </column>
          <column>
          <field refid="competency"/>
          </column>
          <column>
          <field refid="start"/>
          <field refid="due"/>
          </column>
          <column>
          <field refid="state"/>
          </column>
          <column>
          <field refid="link"/>
          </column>
      </plan-layout>
      
      Expand
    4. The rest of the fields should be in separate columns. You can also compare your plan layout to the sample code in the Course Files titled Code For Plan Layout 2023.xml.

    5. Select column weights that will work best for your template. Larger weights will take up more horizontal space on your Development Plan.

    6. Check to make sure the order of your field definitions matches the order of your Field permissions and plan layout. This simplifies maintenance and troubleshooting. Use the order from the plan layout code sample as your guide.

  3. Save the file with a new version number.

  4. Validate the file against the provided DTD (objective-template_4_0.dtd).

  5. Import the new file to Provisioning.

    1. Navigate to ProvisioningImport/Update/Export Development Plan Templates.

  6. Test the changes.

    1. Log in as your CDPAdmin user and add a new goal. Test each step of the different configuration from the field permission and layout exercises to make sure the fields, permissions, and layout are as required.

    2. Proxy as Felicia Ford to test Manager permissions. Felicia should be able to see all fields but should only be able to edit the "link" field. She should also be able to change privacy and category.

  7. Make any changes you feel are necessary if the tests are not working out as expected.

Development Plan Configuration

Development Plan Configuration in Admin Center vs. XML

There are advantages and disadvantages to configuring development plans in either Admin Center or using XML. For example, configuring items in Admin Center prevents consultants from making any syntax errors. On the other hand, certain items can only be added using XML. Depending on the items you’re configuring, you’ll want to choose the more appropriate configuration method.

One strategy is to add as much as possible through Admin Center, and then complete the configuration in XML.

The table below lists some examples of advantages and disadvantages of both configuration methods.

Configuration in Admin Center vs. XML

 

Admin Center

XML

Fields

New fields are automatically added to Permissions and Plan Layout. Additionally, fields such as "enum" are easier to add (multiple values, color picker tool, etc.). Not all fields, nor all field options, can be added through Admin Center.

All fields and field options can be added with XML and validated against the DTD. Additionally, some XML editors provide code completion.

Switches

Only one is available in Admin Center (CPM).

All switches can be configured.

Category

Easy to add, but cannot control Category ID.

Complete control over Category ID.

Permissions

Cannot be directly controlled – new fields automatically added.

Complete control, but new fields must be added manually.

Plan Layout

Cannot be directly controlled – new fields automatically added.

Complete control, but new fields must be added manually.

Standard Comment Field

The standard comment field is used to store public comments for the goals. This field will always include the author's name and the time stamp when a comment is entered.

It is not possible to add this field in the Development Plan template from Manage Templates. The configuration is done in the XML. The field ID comments is in the plural form, whereas the field type comment is in the singular form:

Code snippet
<field-definition id="comments" type="comment" required="false" detail="false" viewdefault="on" showlabel="true" field-show-coaching-advisor="false" cascade-update="push-down">
   <field-label>Comments</field-label>
   <field-label lang="en_US">Comments</field-label>
   <field-label lang="fr_FR">Commentaires</field-label>
   <field-description>Comments</field-description>
   <field-description lang="en_US">Comments</field-description>
   <field-description lang="fr_FR">Commentaires</field-description>
  </field-definition>

Expand

Like any other fields, the standard comment field has to be added to the Field permission and to the layout in the Development Goal Plan Template XML. These comments can only be added when creating or editing a goal. Once a comment is created, it is not possible to delete it.

As another option, the comments can be displayed in the plan layout using a switch.

Switches

Switches are used to enable or disable features in a Development Goal Plan template. The default value of the switches is off.

As an example, the standard comment field can have its regular view modified by adding the "threaded feedback" switch. This switch allows users to add, edit, or delete their comments without opening the goal. Switches have to be added in the XML file after the <obj-plan-due> date line and before the text replacement section.

Code snippet
 < obj-plan-start>01/01/2018 </obj-plan-start>
 <obj-plan-due>12/31/2020 </obj-plan-due>
 <switches>
  <switch for="threaded-feedback" value="on"/>
  <switch for="continuouspm-integration" value="off"/>
  <switch for="show-competency-browser" value="on"/>
  </switches>
  <text-replacement for="Instructions">
Expand

When the threaded-feedback switch is configured, the comment field is not visible in the goal pop-up window. This is the correct and expected behavior. Users will be able to add, edit, or delete their own comments directly from the plan layout.

There are other switches that can be added for different functions, and we’ll add them as they become necessary.

Add the Comment Field and Related Switch

To learn how to complete this exercise, watch this video:

Practice adding the Comment Field and Related Switch:

As a consultant, you are asked to add a comment field to the Development Plan, using the threaded feedback format.

Steps

  1. Export the latest version of your Development Plan XML from Provisioning, rename it by adding a new version number, and open it in a preferred XML Editor.

    1. Development Plan template XML can be found in Provisioning under the section Managing Plan Template. The link is called Import/Update/Export Development Plan Templates.

      Note
      Make sure you’re exporting your Development Plan template, and not the template of another learner. Follow the line of the template with your ID number and name in the template name.
  2. After the last field definition code add the Comment field definition.

    Code snippet
    <field-definition id="comments" type="comment" required="false" detail="false" viewdefault="on" showlabel="true" field-show-coaching-advisor="false"> 
        <field-label>Comments</field-label>
        <field-label lang="de_DE">Kommentare</field-label>
        <field-description>Comments</field-description>
        <field-description lang="de_DE">Kommentare</field-description>
    </field-definition>
    
    Expand
    1. Sample code for this exercise can also be found in the THR95 Code for Comment Field 2023.xml configuration file.

  3. Add the Comment field to the Write Field Permissions.

    Code snippet
    <field-permission type="write">
        <description><![CDATA[The following users have write permission]]></description>
        <role-name><![CDATA[E]]></role-name>
        <role-name><![CDATA[EM]]></role-name>
        <field refid="comments"/>
    </field-permission>
    
    Expand
  4. Add the Comment field to the Plan Layout stacked with the Name field.

    Code snippet
    <plan-layout>
        <column weight="10.0">
            <field refid="name"/>
            <field refid="comments"/>
          </column>
    
    Expand
  5. Save the file with a new version number.

  6. Validate the file against the provided DTD (objective-template_4_0.dtd).

  7. Import the new file to Provisioning.

    1. Navigate to ProvisioningImport/Update/Export Development Plan Templates.

  8. Test the changes.

    1. Log into the instance using your CDPAdmin login.

    2. Create a new goal (or edit an existing goal) to see the new comment field.

    3. Add a new comment and save the goal. The new comment should appear below the Goal Name.

    4. Proxy as manager Felicia Ford and navigate to Development. Change your goals by clicking on Felicia’s name in the top right and selecting your name from the list.

    5. Edit the goal from step b and add a new comment . Two comments should now be listed.

  9. Add the Threaded Feedback switch code to the XML.

    1. The switch code gets added with other switch codes, after the <obj-plan-due> line.

      Code snippet
      <obj-plan-due>12/31/2023</obj-plan-due>
      
      <switches>
          <switch for="threaded-feedback" value="on" />
      </switches>
      
      <text-replacement for="Instructions">
      
      Expand
    2. Be sure to delete or comment out the Comment field from the Plan Layout.

  10. Save the file with a new version number.

  11. Validate the file against the provided DTD (objective-template_4_0.dtd).

  12. Import the new file to Provisioning.

    1. Navigate to ProvisioningImport/Update/Export Development Plan Templates.

  13. Test the changes.

    1. Log into the instance using your CDPAdmin login.

    2. You should now see the comments under the goal on the main development screen. While logged in as CDPAdmin you can only edit/delete the comments you added, not the comment added by Felicia.

    3. Add a second comment to the goal you added and save it.

Competencies Field Configuration

The "competencies" field type links development goals to one or more competencies that the employee is trying to develop.

Code snippet
<field-definition id="competency" type="competencies" required="false"  detail="false"  viewdefault="on"  showlabel="false" field-show-coaching-advisor="false">
    <field-label>Competencies</field-label>
    <field-description>Competencies</field-description>
    <field-format>use-competencies</field-format>
Expand

You can only have one "competencies" field per development plan. But that "competencies" field can be displayed in more than one way. The screenshot above shows a configuration that allows a user to select multiple competencies.

The Competency Browser

You can enable access to the Competency Browser by adding a switch in the Goal Plan template XML, so that the user can add additional competencies to the Development Goal that are not currently displayed:

Code snippet
<switches> 
<switch for="show-competency-browser" value="on" />
</switches>
Expand

A Competencies link appears next to the list of available competencies in the Add Development Goal window. Clicking on the link displays the Add Competencies window, where competencies are organized into hierarchical lists of categories under tabs for each competency library. Users can select the checkbox next to one or more of these competencies and choose the Select button to add competencies to the development goal.

An Add Competencies link appears next to the list of available competencies when you add or edit a development goal.

Linking Development Goals to Single Competencies

To force users to pick a single competency, preventing them from selecting multiple competencies, set the field-format tag (within the field-definition block) to "use­ competencies-single" as follows:

Code snippet
<field-definition id="competency" type="competencies" required="false"  detail="false"  viewdefault="on"  showlabel="false" field-show-coaching-advisor="false">
    <field-label>Competencies</field-label>
    <field-description>Competencies</field-description>
    <field-format>use-competencies-single</field-format> 
Expand

The competencies field will then use a drop-down list, instead of a list with checkboxes.

When use-competencies-single is used, the goal screen will change so only one competency can be selected.

The list of competencies that displays can be derived in many ways. See the configuration handbook for more details/information.

To use behaviors in this field instead of competencies, set the field-format tag (within the field-definition block) as follows: <Field-format>use-behaviors</ field-format>.

The competencies field will then list behaviors within their parent competencies. At this time you cannot use the single-select option for behaviors.

Note
Search the objective-template DTD and the CDP Configuration Guide for more details on the <field-format> tag.

Defining a Competencies Source

The Development Plan template uses a set of specific competencies by adding filters inside the XML template. To include competencies from any of the following, you can add a <competency-filters> tag that defines the sources of competencies that the Development Plan will use. These are:

  • Forms
  • Roles
  • Categories
  • Libraries
  • Exclude hidden competencies
  • Exclude skills & questions

Below are some examples of the <competency-filters> tag:

Source of Competencies:

Forms and Roles: No configuration

Forms

Note
There are some cases when custom competencies will not immediately appear as options to be selected using a competency browser. See the following KBA for more details: https://launchpad.support.sap.com/#/notes/2259810

Also see Wiki article: https://wiki.scn.sap.com/wiki/display/SAPSF/Development+Plan+-+Competency+Filters

Code snippet
...
</default-category>
<competency-filters>
<exclude type="roles"/>
</competency-filters>
<field-definition ...
Expand

Roles

Code snippet
...
</default-category>
<competency-filters>
<exclude type="forms"/>
</competency-filters>
<field-definition ...
Expand

Roles, except hidden competencies

Note
Hidden competencies are those competencies that have their status set to Hidden. This is set in each competency definition.
Code snippet
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="hidden"/>
</competency-filters>
<field-definition ...
Expand

A specific category

Code snippet
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<include type="category" match="category name"/>
</competency-filters>
<field-definition ...
Expand

A specific library

Code snippet
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<include type="library" match="library name"/>
</competency-filters>
<field-definition ...
Expand

Multiple categories

Code snippet
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<include type="category" match="category name A"/>
<include type="category" match="category name B"/>
</competency-filters>
<field-definition ...
Expand

A specific category of a specific library, except hidden competencies

Code snippet
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<exclude type="hidden"/>
<include type="category" match="category name" library="library name"/>
</competency-filters>
<field-definition ...
Expand

Add the Competencies Browser Switch to the Development Plan

To learn how to complete this exercise, watch this video:

Practice adding the Competency Browser Switch to the Development Plan:

As a consultant, you are asked to add a competencies browser to the Development Plan.

Steps

  1. Export the latest version of your Development Plan XML from Provisioning, rename it by adding a new version number, and open it in a preferred XML Editor.

    1. Development Plan template XML can be found in Provisioning under the section Managing Plan Template. The link is called Import/Update/Export Development Plan Templates.

      Note
      Make sure you’re exporting your Development Plan template, and not the template of another learner. Follow the line of the template with your ID number and name in the template name.
  2. Add the Competency Browser switch code.

    1. The switch code gets added with the other switch codes, after the <obj-plan-due> line.

      Code snippet
      <switch for="show-competency-browser" value="on"/>
      
      Expand
    2. Sample code is also provided for the competency field in the configuration file titled THR95 Code For Competency Field 2023.xml.

  3. Change the competencies selection from multiple competencies to single competencies.

    1. Change the <field-format> line in the Competencies Field Definition from use-competencies to use-competencies-single.

      Code snippet
      <field-definition id="competency" type="competencies" required="false" detail="false" viewdefault="on" showlabel="false" field-show-coaching-advisor="false">
          <field-label>Competencies</field-label>
          <field-description>Competencies</field-description>
          <field-format>use-competencies-single</field-format>
      
      Expand
  4. Save the file with a new version number.

  5. Validate the file against the provided DTD (objective-template_4_0.dtd).

  6. Import the new file to Provisioning.

    1. Navigate to ProvisioningImport/Update/Export Development Plan Templates.

  7. Test the changes.

    1. Log into the instance using your CDPAdmin login.

    2. Create a new goal to see the competency field changes.

Log in to track your progress & complete quizzes