Skip to end of metadata
Go to start of metadata

Purpose

The purpose of this page is to explain the permission model used by the Career Development Plan and provide some examples of common configuration options. 

Overview

Development Plan permissions work similarly to Goal Plan permissions. You have “access” permissions that define who will be able to access the Development Plan with their user, which is configured in RBP, and you have the permissions over the content and actions inside the Development Plan, which are defined in the XML code of the Development Plan template. 

Access Permissions

Access permissions are configured in RBP (Role-Based Permissions) and can be managed by the administrator of the instance; so if you want to remove access to the Development Plan for certain users (or for the entire instance population), this can be done without any assistance from a Support representative. 

There are two permissions that control access to a Career Development Plan: 

  • Career Development Plan (CDP) Access Permission: this permission allows the user to access the Development Plan tab within the Development module. It does not have a target population, so the content within the Development Plan tab is controlled by other permissions. This permission can be found when editing a permission role under the "Career Development Planning" section.


  • Goal Plan Permission †: this permission controls access to the plan templates over a specific target population. This includes Goal Plan, Development Plan and Learning Activities templates, but for CDP, only the Development and Learning Activities templates are relevant. It's important to note that this permission has a target population, therefore, you can give access to an user for a specific target population. For example, you may want to grant access for managers to access the Development Plan of their direct reports. 


    The access to the content/actions will still be restricted by the permissions defined in the Development Plan template XML. So, even if you grant this Goal Plan Permission so that everyone can access the Development Plan of everyone else, but in the Development Plan template it is defined that only the employee and its manager have read permissions, the users will be able to access the plan of everyone else, but will not see any data. 

    The other way around is also true: you can configure the Development Plan XML so that everyone have read access to the development goals of everyone else, but restrict the target population of the Goal Plan Permission, so that only a limited number of users has access to the Development Plan. This permission setting may be useful when you want to grant access to users that don't have a direct relationship to the employee. For example, if you want to grant access to a group of HR users to see the development goals of everyone, you could configure the Development Plan template to have read permissions for everyone, then restrict the Goal Plan Permission in RBP, so that only the HR users have access permissions to everyone (other roles would have limited target population, such as employees to themselves, managers over their direct reports, etc). 

    Learning Activities template

    If you want the user to have access to see and add Learning Activities to the Development Plan, you'll also need to grant this Goal Plan Permission for the Learning Activities template.

Content Permissions

The content permissions controls the visibility of the fields of the Development Goals and the actions that a user is allowed to take. Their target populations are based on the relationships between the users, so they are not as flexible as RBP's options (for example, you cannot define groups of users to grant the permissions). 

XML Permission User Relationships

In the Development Plan and Learning Activity template XML, the permissions are defined based on user relationships, such as employee themselves (E), employee's manager (EM), employee's HR manager (EH). The following permission roles can be used: 

Role Name (to be used in XML)Description

*

Everyone

E

Employee/owner

EM

Employee's manager

EMM

Employee's second level manager

EM+

Employee's manager and levels above in the reporting hierarchy

EMD

Employee's manager's direct reports, i.e. coworkers/peers

EH

Employee's HR representative

ED

Direct report

ED+

Any level of direct reports below in the reporting hierarchy

EDD

Second level direct report

EX

Employee's matrix manager

ECEmployee's custom manager
EAEmployee's 2nd manager 
EJEducational Representative *
ELLearning Administrators *

* The EJ and EL roles (Educational Representative and Learning Administrators) are only available for instances with LMS integration. 

Educational Representative (EJ) and Learning Administrators (EL) roles

The Educational Representative and Learning Administrators roles are HR roles for users who manage learning activities for a large number of employees. 

Learning Administrators (EL role) are the main coordinators in Learning system. Users in this role can assign roles and permissions, upload/download, edit, change, delete Learning Activities and Learning Activity libraries in Learning system (LMS). Similar to the Admin role in BizX, that can change and edit content from Admin Center and other modules.

Educational Representatives (EJ role) are defined by the Learning Administrators and the permission access will be based on each company's requirements. 

The Admin Center tool "Import User Relationship for Learning Administrator and Educational Representative" is available on instances with LMS integrated. In this tool you can define the relationship between users who report to these roles, so you can grant permissions based on these roles. 

Content Permission Types

The following content permissions can be configured: 

  • View / Write permissions: controls the fields which a given role can view and write to when creating / editing the development goal.
    <field-permission type="read">
    <description><![CDATA[Employees, their managers and matrix managers may read the fields. ]]></description>
    <role-name><![CDATA[E]]></role-name>
    <role-name><![CDATA[EM]]></role-name>
    <role-name><![CDATA[EX]]></role-name>
    <field refid="desc"/>
    <field refid="start"/>
    <field refid="due"/>
    <field refid="state"/>
    <field refid="comments"/>
    </field-permission>
    <field-permission type="write">
    <description><![CDATA[Employees, their managers and matrix managers may read the fields.]]></description>
    <role-name><![CDATA[E]]></role-name>
    <role-name><![CDATA[EM]]></role-name>
    <role-name><![CDATA[EX]]></role-name>
    <field refid="desc"/>
    <field refid="start"/>
    <field refid="due"/>
    <field refid="state"/>
    <field refid="comments"/>
    </field-permission>

     

  • Action permissions: the following permissions control the actions that the users can take in the Development Plan. 

    Action NameDescriptionUsed in Learning Activities template
    private-accessallows visibility to private goals 
    createallows the user to create development goals / learning activitiesYes
    deleteallows the user to remove development goals / learning activitiesYes
    shareallows the user to make a private goal public 

    Example:
    <permission for="private-access">
        <description><![CDATA[Only the employee and manager may view private goals in a user's plan.]]></description>
        <role-name><![CDATA[E]]></role-name>
        <role-name><![CDATA[EM]]></role-name>
    </permission>

Conditional Permissions

It's also possible to apply conditions to when a certain permission rule will be applied by adding a <condition> element to the XML definition. For example, the below code allows managers to see the "purpose" field only when the Development Goal's status is equal to "Completed": 

<field-permission type="read">
<description><![CDATA[Only Managers may read purpose when Completed]]></description>
<condition><![CDATA[status eq Completed]]></condition>
<role-name><![CDATA[EM]]></role-name>
<field refid="purpose"/>
</field-permission>

Condition element

The "condition" element is only designed to work with Learning Activities and not Goals.

Configuration Scenarios

This section aims to provide examples of common requirements and the required configuration to meet the requirements. 

Example 1

Only the employee, manager and HR Manager may see and take all actions on development goals.

Development Plan template: 

  • Read and Write permissions: granted to roles E, EM and EH with access to all fields.
  • Action permissions: granted to roles E, EM and EH for all actions.

RBP: create three roles with "Career Development Plan (CDP) Access Permission" and "Goal Plan Permission" for the respective Development Plan template and the following granted and target populations: 

  • To all employees in self.
  • To the managers with target population of direct reports. 
  • To the HR managers with target population of HR reports. 

Example 2

Only the employee and manager may see and take all actions on development goals. The HR Manager may see all fields, but may not create / edit development goals. 

Development Plan template: 

  • Read permissions: granted to roles E, EM and EH with access to all fields.
  • Write permissions: granted only to roles E and EM with access to all fields, since the HR manager may not write to the development plan. 
  • Action permissions: granted to roles E and EM for all actions.

RBP: same as example 1, since the RBP permissions only control access to the Development Plan. 

Example 3

Only the employee and manager may see and take all actions on development goals. A group of HR Business Partners (without a direct relationship to the employee) needs to see all Development Goals for all users. In this case, since the CDP template permissions work based on user relationships and the group of HR Business Partners does not have a direct relationship to the employees they need access to, it's not straight-forward to resolve this requirement, but there are two options: (1) create a relationship between the HR Business Partners and all employees, setting them as Matrix Managers, for example, or (2) open the access in the CDP template and use RBP to restrict access to only the relevant roles. 

Example 3 - Option 1 - Create a relationship between the users

SuccessFactors offers many fields to establish relationships between the users. The idea here is to use one of those fields to establish a relationship between the group of HR Business Partners and all employees, so that the CDP template permissions can be granted based on this relationship. 

Fields that allow one-to-many relationship

The Matrix Manager and Custom Manager fields allow to associate one employee to many matrix or custom managers, so they are better suited for this scenario where access must be granted to a group of users.

UDF (User Directory File): using the Matrix Manager field, associate all employees to the group of HR Business Partners.

Development Plan template: 

  • Read permissions: granted to roles E, EM and EX (matrix manager) with access to all fields.
  • Write permissions: granted only to roles E and EM with access to all fields,
  • Action permissions: granted to roles E and EM for all actions.

RBP: create three roles with "Career Development Plan (CDP) Access Permission" and "Goal Plan Permission" for the respective Development Plan template and the following granted and target populations: 

  • To all employees in self.
  • To the managers with target population of direct reports. 
  • To the group of HR Business Partners with target population of everyone in the instance.

Example 3 - Option 2 - Open access in the template and restrict it in RBP

 If it's not possible to define a relationship between the employees and the group of HR Business Partners, the only other option is to open the access to everyone in the template and then restrict it via RBP, so that the information is only available to the people who should be able to see it. 

Development Plan template: 

  • Read permissions: granted to everyone (role *). 
  • Write permissions: granted only to roles E and EM with access to all fields,
  • Action permissions: granted to roles E and EM for all actions.

RBP: create three roles with "Career Development Plan (CDP) Access Permission" and "Goal Plan Permission" for the respective Development Plan template and the following granted and target populations: 

  • To all employees in self.
  • To the managers with target population of direct reports. 
  • To the group of HR Business Partners with target population of everyone in the instance.

The "read" permissions to everyone would allow anyone in the instance to see the development goals of anyone, but then the access to the Development Plan will be restricted in RBP. 

Related Content

Related Documents

Career Development Planning: Implementation and Administration Guide - Setting Up Permissions

__________________________________________________________________________________________________________