The SuccessFactors Employee Central Position Management feature

[lukemarson]

In my previous SuccessFactors Employee Central blogs, I had discussed the Organization Structure and Pay Structure. The third element to managing the enterprise is the Position object and the Position Management feature. In this blog, I will provide an overview of the Position object and how it works in Employee Central, as well as cover the Position Management feature and how it impacts organizational management. In addition, we will look at some of the standard reporting options and integration points.

SAP provide a very detailed Position Management handbook on SAP Service Marketplace (S-user required) that I recommend reading if you want to learn the full details of Position Management, since it contains the wealth of information on the Position object, using and configuring Position Management, and the system behavior for the various scenarios of Position Management. Since this information is readily accessible to SAP customers I will not repeat any of the details provided in the handbook. In addition, I will not be covering Metadata Framework-specific features such as permissions or creating scenario-based workflows.

A quick note about hyperlinks in this blog

Please note that throughout this blog there are many references to handbooks and implementation guides on SAP Service Marketplace. Since SAP are regularly updating and modifying handbooks and implementation guides to include the latest features and releases then over the course of the lifetime of this blog some links may change. Wherever I have referenced a handbook or implementation guide I have also included a link to its parent folder with the text “SAP Service Marketplace”, which should change less frequency. Please let me know if you find any broken links! Now let’s take a look at the Position object.

Position object

The Position object is a Generic Object, meaning that it is built and configured in the Metadata Framework. This brings many benefits, such as:

• Easy configuration of the Position object fields
• Creation of rules to meet a variety of scenarios
• Scenario-based workflow
• Rule-based data propagation
• Auto-creation of Position Code
• Showing pending workflow data or not
• Associations with other objects
• Robust, granular, and structural-based security options

Various functions are provided in the Rules Engine so that rules can be built to query Positions and their incumbents, such as Get Incumbent by Position, Get Next Available Manager By Position and Get Number Of Child Positions. The Rules Engine can also be used to create rules to trigger different workflows based on different scenarios, such as approving changes to positions that have or are above a certain level of grade or approving a change in To Be Hired status.

A standard Position object definition is provided, which a customer can adapt to their own needs using the standard Metadata Framework functionality. This object definition can be seen in the screenshot below:

Positions are assigned to an employee in Job Information, above the Organization Structure section. If configured, the Position Entry Date and Time in Position fields are also displayed. The screenshot below shows a Position assigned to an employee:

Positions can have a parent Position, so that a tree structure can be created and visualized in the Position Org Chart. This is known as the Position Hierarchy. The Position Hierarchy in the Position Org Chart can be seen below:

Position Management

Position Management provides standard and configurable behavior in the system to manage positions across the enterprise. While a customer does not need to use Position Management in order to use the Position object, it does provide many features and benefits.

Let’s take a look at some of the key features provided in Position Management and then at some of the general configuration settings.

Shared Positions

Employee Central supports sharing of positions by one or more employees. This must be set for each shared position individually by setting the Multiple Incumbents allowed field value to Yes.

Capacity Control

Capacity Control enables the FTE of the incumbent(s) of a position to not exceed the FTE value defined for the Position. This feature is particularly useful for retaining stable headcounts and for budgeting.

The system checks the FTE value of the incumbent(s) against the FTE value of the Position in the following scenarios:

1. During the New Hire transaction
2. A new Position is assigned to an employee or the FTE of an employee is changed
3. The FTE value of the Position of an employee is changed
4. Either the Position or the employee’s FTE value is changed on an historical Job Information record
5. During a Position transfer or Position reclassification takes places and the system searches for a suitable position

This must be set for each position by setting the Capacity controlled field value to Yes and defining a value for the Target Capacity (FTE) field.

Matrix Relationships

An employee’s Job Relationships can be inherited from a Position when the Position is assigned to the employee. On the Position these are called Matrix Relationships. The holder of each Position defined under the Matrix Relationships section of a Position will be synchronized to an employee’s Job Relationships.

This enables Position-based Job Relationships to be maintained on Positions rather than individually for each employee and thus enables consistency across the enterprise. It also enables additional permissioning for incumbents of Positions that are defined as Matrix Relationships of another Positions.

For more details on the exact behavior of Matrix Relationship assignments, please see the Matrix Relationships section of the Position Management handbook on SAP Service Marketplace.

Position Types

The Type field can be used to identify different types of positions, for which standard system behavior can be modified. The system comes with two standard Position Types (Regular and Shared Position), but custom Position Types can be created in the Manage Data UI.

This feature is particularly useful if certain types or groups of positions require different types of changes to other types or groups of positions. For example, shared positions may require different types of manager re-assignment if the manager leaves the parent position, since the two incumbents may have different managers or matrix managers.

There are three types of system behavior that can be modified for each Position Type:

1. Trigger a workflow for changes to an employee’s Job Information that change a Position and if those Position changes need to be synchronized to one or more incumbents
2. When a manager leaves their position, determine to which employee the direct reports of the manager should report to
3. If the Position Hierarchy is changed, specify how the reporting line should change

In addition, rules can be setup so that they respect the Position Type and could therefore drive different behavior in data synchronization, workflow triggering, etc.

The screenshot below shows the settings for a Position Type:

For more details on the available settings, please see the Position Types section of the Position Management handbook on SAP Service Marketplace.

Right to Return

On the Position, it can be determined whether an employee who goes on a Global Assignment or a Leave of Absence has the right to return to that Position. This feature can only be used if Time Off and/or Global Assignments are used in the system. The feature is based on two rules that are used to determine:

1. If the incumbent remains in their Position while on Global Assignment/Leave of Absence
2. If the incumbent can return to their Position when the Global Assignment/Leave of Absence ends

Right to Return is also visualized on the Position Org Chart.

For more details on the exact behavior of Right to Return and the available settings, please see the Right to Return section of the Position Management handbook on SAP Service Marketplace.

Position Transfer or Position Reclassification

When a Position Transfer or Position Reclassification takes place, information maintained on the Job Information for an employee will be synchronized to the Position object assigned to the employee. The fields that are synchronized are defined by a rule that can be assigned in Position Management Settings in the field Rule for Synchronizing Position after Job Information Change.

In most cases the system determines a Position Transfer as a change of manager for an employee, although in the case of a promotion an employee would move to a new position without a change to the existing position. The system determines a Position Reclassification as changes to an employee’s Job Information by a manager. These are technically defined on the relevant Event Reason Foundation Objects by setting the value of the Follow-Up Activity on Position field to either Position Reclassification or Position Transfer.

When a Position Transfer takes place, the system searches for a position under the employee’s manager’s Position that has the To be hired field value set to Yes and assigns the employee to this Position. If no Position is found then a new Position is created and the employee is assigned to it. The Position’s FTE value will be taken from the employee’s FTE field. The To be hired field value of the “old” Position remains as No and the To be hired field value of the “new” Position is set to Yes. In addition, direct reports of the employee are transferred to the employee’s “old” manager.

When a Position Reclassification takes place, the system changes the Position of the employee as per the rule assigned in Position Management Settings. In the case of a shared position the system will perform a position transfer instead.

The system can be changed so that it does not search for a new Position. This is done by setting the Search for Position in Position Transfer field value to No in Position Management Settings.

Data Propagation and Synchronization

Although Employee Central supports propagation of data to or from the Position object, Position Management can define specific data propagation rules for certain Position Management scenarios so that objects and employee data can be kept synchronized when changes are made. There are three scenarios where data propagation is used:

1. Propagating Job Classification data to a Position when a Job Classification is assigned to or changed for a Position
2. Propagating Position data to an employee’s Job Information when a Position is assigned or the employee’s assigned Position is changed
3. Propagating Job Information to a Position in the chase of a Position Transfer or Position Reclassification

Rules are used to determine which fields are to be propagated and these rules are assigned in the Position Management settings. For propagation of Job Classification data to Position many of my clients typically propagate data such as Job Title, Job Level, Employee Class, organizational data (i.e. Company and Department), and FTE.

Future-dated propagation (called Forward Propagation) is a standard feature of the system and is typically used for Right to Return.

Configuration Settings

There are various configuration settings in the system that determine the overall behavior of the system and thus how Position Management works. Some of these are related to the features that were discussed above. These configuration settings are accessed in OneAdmin in Employee Files > Position Management Settings. The user interface of Position Management Settings is split into 5 tabs:

1. General
2. Hierarchy Adaptation
3. Synchronization
4. UI Customizing
5. Right To Return

The General tab is where the following types of features are configured:

• Whether Position Types are used
• How the To Be Hired field should behave during assignment and unassignment of an employee to a Position
• How an employee’s Position assignment should be validated (for multiple incumbents and capacity control) when employee data is imported via a Job Information import
• If the Position code should be automatically generated

The General tab can be seen in the screenshots below:

The Hierarchy Adaptation tab defines which hierarchy – Position Hierarchy, Reporting Hierarchy, or neither – the system leads with. This means that the other hierarchy is adapter based on changes to that hierarchy.  For example, John Smith moves to a vacant Position that has 3 direct reports and so the manager of the new employees will change to John Smith. Also in this tab, the behavior of the hierarchies during a Position Import and Job Information import can be defined.

The Synchronization tab determines the behavior of the system when synchronizing data from a Position to an employee’s Job Information, and vice-versa. This includes the rules for defining fields used in synchronization of Position to an employee’s Job Information and vice-versa, as well as whether a Position is searched for a reclassification or transfer of a Position and which area of the organization should be used for retaining a stable headcount.

The UI Customizing tab defines:

• The rule used to specify which fields of a Position that are copied to a new Position when one is created in the Position Org Chart
• In MSS, whether the list of Positions should be filtered by Company
• Whether to display the Positions Under Employee field in the New Hire screen, Job Information screen in MSS, and in the History screen

The Right To Return tab determines the rules and event reasons that defines the behavior of the Right to Return feature.

Position Profiles in Job Profile Builder

Job Profile Builder enables Job Profiles to be created for Position objects and not just Roles. These can then be used in creating requisitions or in skills management. It makes a lot of sense to have Job Profiles for Position objects, since many organizations will have some positions have specific competencies, skills, or other requirements that are unique to that instance of a position. Regional or country-specific positions are a great example of where local skills or qualifications can be needed for what is otherwise the same position across each region or country.

The screenshot below shows all of the Position objects assigned to the Maintenance Manager Role:

The screenshot below shows skills mapped to a Position object:

The screenshot below shows a Job Profile for a Position object:

Reporting

SuccessFactors offers two types of reporting for Employee Central that can be used to report on Positions:

• Detailed Reporting
• Employee Central Advanced Reporting

Detailed Reporting provides reporting capabilities for Metadata Framework objects, which of course includes the Position object. Through this reporting type users can build reports using any array of fields on a Position. In addition, the calculation capabilities with Detailed Reporting can be used to perform functions such as data aggregation or if/then/else statements.

Employee Central Advanced Reporting provides over 70 out-of-the-box reports that customers can use or re-use as templates for their own reports. It is technically a sub-component of Detailed Reporting. Three exist that can be used for Position Management reporting purposes:

• Position Overview
• Position Details
• Disparities between Reporting Line and Position Hierarchy

The Position Overview report provides a list of all positions in the company with the pre-defined position fields, such as Name, Code, Status, Start Date, End Date, Job Code, Job Level, Employee Class, Company, Business Unit, Department, etc. A screenshot of this report can be seen below:

The Position Details report is a more detailed version of the Position Overview report, and thus provides a more detailed overview of all positions in the company. It displays all fields shown in the Position Overview, along with details of the incumbent like First Name, Last Name, Person ID, Employment Status, FTE, etc. A screenshot of this report can be seen below:

The Disparities between Reporting Line and Position Hierarchy report identifies any differences between the reporting line (the reporting Manager whom an employee reports to) and the position hierarchy (a position-to-position reporting structure). It lists all positions with the incumbent, the incumbent’s manager, the incumbent’s manager’s position and the parent position of the incumbent’s position. Any differences between the incumbent’s manager’s position and the incumbent’s position’s parent position are highlighted in the Discrepancy column with a description of the discrepancy in the Comment column.

In addition, Positions can be shown in reports made on employee data in Ad-Hoc Reporting. The Job Information (Date Range) domain enables reports to be created using data from Job Information (e.g. Position or Position Entry Date fields) as well as all fields of the Position object that an employee is assigned to. However, Ad-hoc Reporting is not the optimal solution for reporting on Position object data and it is not recommended to use it for Position reporting.

Integrations

The Position object is integrated with both Recruiting Management and Succession Planning. Additionally, the SuccessFactors OData API enables Position object data to be integrated with other systems.

Recruiting Management

Naturally there is integration with Recruiting Management, as one might expect. Requisitions can be created (for both current date and for a future date) from Position objects in the Position Org Chart, with an assigned requisition visible on the Position in the Position Org Chart (both for current and future-dated requisitions) and navigation to the requisition is possible. A candidate can be automatically assigned to the Position in the requisition in the “Pending Hires” transaction in Employee Central.

The Rules Engine offers two functions: the ability to derive a requisition template to be used for the Position object and the ability to define field mapping between the Position object and the new requisition.

The flow diagram below – taken from the Position Management handbook – shows the flow of the Recruiting Management integration.

More details can be found in the Position Management handbook on SAP Service Marketplace.

Succession Planning

For Position-based succession planning, Succession can leverage the Position object from MDF and share the same Position Org Chart that is seen in Company Info. This changes the way that various succession planning processes key off the Job Code; when not leveraging the MDF position object then the position incumbent’s job code drives succession planning processes while with the MDF position object the position’s job code drives succession planning processes.

More details can be found in the Succession Planning w/ MDF Positions implementation guide on SAP Service Marketplace.

Job Profile Builder

As mentioned above, Position objects are integrated into Job Profile Builder to enable Job Profiles to be created specifically for positions.

Integration with external systems

The SuccessFactors OData API enables query, insert, update, and upsert of Generic Object data, including Position object data. Data is not deleted, rather it would be date-delimited. This enables Position data to be integrated with any system, so long as the system or middleware supports the OData protocol.

Exposure of a Generic Object via the OData API can be controlled on the Generic Objects object definition by setting the appropriate value (Editable, Read Only or Not Visible) of the API Visibility field.

More details can be found in the Metadata Framework implementation guide on SAP Service Marketplace and the HCM Suite OData API User Guide on help.sap.com/cloud4hr.

How does this all compare to SAP ERP HCM?

In SAP ERP HCM the position is a mandatory object that – like in Employee Central – can be independent of a Job. However, Position Management in Employee Central adds a significant wealth of functionality that I have not yet seen used significantly in SAP ERP HCM. Features such as position control, position types, position transfers and reclassifications, and matrix relationships add significant value to the system. The Position object is also much more flexible than in SAP ERP HCM, so customers can define fields and rules for the Position object, as well as configure settings and create rules to define how the system behaves in certain employee lifecycle scenarios.

SAP ERP HCM customers should find that Position Management is much more robust in Employee Central than they might be used to in SAP ERP HCM and therefore have much more control of how the system behaves in relation to how Positions are managed within their organization. This would certainly be a benefit to most of the SAP ERP HCM customers I have come across in my career.

Roadmap

SAP are committed to continued enhancements for Position Management. In the b1508 release they are planning to introduce mass changes functionality for positions and incumbents (focused on organizational entities that need to be applied in positions and job information) and adding Pay Ranges and related attributes to the Position object definition. The image below shows some of the public roadmap items that have recently been delivered and are planned over the next 6 and 6-12 months.

I also understand that SAP are considering to build a more robust position budgeting module that is likely to be called “Operational Workforce Planning”, although this is not a commitment by SAP and the usual disclaimer applies that this may never be released and that you should always make plans based on existing functionality only

Summary

Position Management provides flexible, configurable, and robust functionality to manage Positions within the organization and maintain stable position headcounts (and therefore budgets), as well provide a wealth of functionality to support position assignments and propagate organization information to employee records. It enables job classifications to act as the source of positions and for positions to influence manager and matrix relationship assignments. Position Management is an important part of SuccessFactors Employee Central and will be further enhanced in future to provide additional functionality and value to customers.

[Pazahanick_Jarr]

Great job with this Luke.

[Former Member]

Excellent article on the SAP SF Position Management. Good to see all the high level details in one click. Thanks for sharing this Luke.

[anipeabraham]

excellent work LUKE

[Former Member]

Thanks Luke.

Our key design principle with position management is simplicity for the manager, and ease of maintenance for all. Traditional position management solutions often offer powerful features, but they are at the expense of simplicity. Rather than being an all or nothing deployment, customers use positions where and how they need them. The position lurks in the background for the manager (almost invisible), but gives HR the control and power that they need. I like to think of it as practical position management.

For ERP customers it is a bit of a mindset change, but once they grasp what we are up to, they really like it.  My advice to consultants and customers is to open your mind and think differently about positions. If you do this, you won't want to go back to traditional position management.

The roadmap for positions is exciting, and I'd like to thank the customers that have worked with us to make this functionality what it has become. Thanks to the SaaS model, we can measure adoption, and I'm very pleased to see many customers deploying position management today.

Thanks for taking the time to write the post.

[lukemarson]

Thanks Thomas - I appreciate your valuable comments. It's kudos to you and your team for making this simplicity happen. I can't agree more that customers and consultants need a different mindset. I think this is a case for SuccessFactors as a whole.

[Former Member]

Nice job, Luke. I'm definitely sharing this with our community.

[former_member188645]

Thanks Luke for sharing this.Position Management is explained very well including JPB.

[npurohit]

Great job Luke!!

[vbaranovskiy5]

Luke, thank you for your valuable work!

Especially for the Roadmap part, as I've a task to provide Pay Range information to Recruiting Requisition. Glad to hear Pay Range will be added to the Position in the standard!

[Former Member]

Thank You Luke, this is very much helpful learning position Mgmt.

[Former Member]

Nice This article has cleared many of of my doubts in Positions management.

[Former Member]

Hi Luke,

Another informed and well researched article. The effort you put in to provide this information and to share with the wider audience is appreciated. Thanks for catching up at HR2015 and all the best for Alaska.

[lukemarson]

Thanks Paul! It was great to meet at HR2015 and I look forward to the next time. Thanks for the best wishes for Alaska!

[nydia_duan]

Hi Luke,

Thanks for the great sharing!

Just a short question: what's the difference/ relationship between Job and Position?

Can we assign an employee to a Job only without Position assignment? Thanks a lot!

[lukemarson]

Thanks Nydia. For the difference between a Job and a Position see this thread:

DIFFERENCE BETWEEN JOBS AND POSITION IN HR

In Employee Central an employee can be assigned to a Job without being assigned to a Position.

[ReenaK]

Hi Luke,

Very useful article. We are integrating Position Management with Recruitment. Have a quick question.

How do I get the Position details into Job Profile Builder(JPB)? When I try to add a job code to a role in JPB, it is getting added as JOBCODE and not as JOBCLASSIFICATION. I noticed that some of the Roles already have Job codes with Positions maintained in JPB.

Not sure how this has happened. Are there any settings in EC in this regard?

Thanks in advance!

Reena

[rajkumarnarasimman]

Great work.. Thank you, for sharing the information

[lukemarson]

Hi Reena,

Can you clarify what you mean by " it is getting added as JOBCODE and not as JOBCLASSIFICATION"?

A Position must have a Job Classification assigned to it in order to use this functionality.

All the best,

Luke

[ReneKolpa]

Great blog Luke! Do you already have ideas about how to handle employees with multiple positions? (we currently have that in SAP HCM)

[Heiko_Lenk]

Hi René,

lately we receive this request from more and more customers. You can actually assign employees to multiple positions today, by creating additional employments for the employee. When doing this, an employment could correspond to a contractual assignment of its own, or it can also represent a simple additional position assignment with slightly different job and organizational attributes.

With b1505 you will find that you can then identify one of the employments as a primary employment, all others will be secondary employments. This flag will then drive behaviour in talent applications, for example you might want to filter out any secondary employments for most processes.

Hope this helps, let me know if you would need more information on this functionality.

Best regards,

Heiko

[Heiko_Lenk]

Hi Reena,

the integration of JBP to EC positions is lightweiht today, as a major feature you can maintain profiles specifically for positions. These profiles will not show up on the position org chart today though. For the integration with Recruitment, you will also not be able to pull the JBP information automatically into the requisition.

However you will be able to use any information from the position, based on the templates that you define. Many customers are successfully and happily using this. There are also further improvements to be expected for the JBP integration in the mid term. 

Best regards,

Heiko

[Former Member]

Great overview Luke!

Question: Can you still use Position Profiles in Job Profile Builder if you only have EC position management enabled but not Succession?

I can't find any details about this in the available documentation.

Best regards,

Maxime

[lukemarson]

Hi Maxime,

Yes you can. Position Profiles are not well documented unfortunately.

All the best,

Luke

[former_member28240]

Thanks for the extensive blog!

I can see distinct advantages to the position reclass and re-org functionality.  Appreciate the time and effort involved with this sharing.

Cheers,

Hillary

[Former Member]

Thank you for your feedback.

Kind regards,

Maxime

[Former Member]

hey buddy, how are you? Get in touch soon.

[Former Member]

Thanks Luke

It certainly helped me alot!!!

Cheers

Pradyp

[Former Member]

Excellent Article Luke, Thanks for taking time to share this information with everyone. We just implemeted employee central and have a question with position management. How do i sync mass changes to positions with job information? The rules are set up in the system to sync job information when position data is chaged but How do i pass the parameter to sync with incumbents when doing mass position changes? when i change one by one on org charts, i have an option to sync but i'm struggling with mass updates.

Any help you can provide is much appreciated.

Cheers, Meher.

[Heiko_Lenk]

Hi Meher,

with the August release it will be possible to apply mass changes to positions from the user interface. This will allow you to make changes not only to the positions, but also to the incumbents of the positions, so the changes will be propagated everywhere.

In the meantime, you can update positions via imports and have the position to incumbent rule fire by adding a column "technicalParameters", that must contain the value "SYNC" in all rows.

Hope this helps,

Heiko

[Former Member]

Many Thanks Heiko. I tried this and I'm getting this error - An error occurred while synchronizing the changes. The position as well as the incumbents have not been updated. It is repeated twice at the end of the data row when i download error log from monitor jobs. Any idea what is causing this?

[Heiko_Lenk]

Hi Meher,

I suspect this is because of a configuration issue in the rule itself. Can you please check the rules against the latest recommendations in the configuration handbook for position management.

thanks,

Heiko

[Former Member]

Luke, it's a great blog, unfortunately there is too little information about JPB - position integration. If my role linked with job code and position, can I set up the profile for role and at the position level, so my job code will have a profile from role, and there will be a unique profile for position.  And as for job profile for position, for employee view in which section employee can see his profile (it also will be a simple link near job code)?

[lukemarson]

Thanks Ekaterina. There isn't really anything else to cover for position integration with JPB, but please let me know if you think I've missed something.

In terms of using positions in JPB, you would setup the profile up at either the Role level or at the Position level. This means you can create a Job Profile at Role level and create a more specific Job Profile for a single Position.

[Former Member]

Thanks for reply Luke, may be you write a similar blog for JPB, because now there isn't a document or course in which we can find all information about it: such as a workflows, acknowledgment, usage it with position based model or job code based model, possible troubles, roadmap, may be possibility to create new references for job profile...

For example, at present in my system I made all settings and created all content and permissions for job profile, but can't see from employee view the link to job profile. And it's not a first time when I implement job profiles...

[lukemarson]

That sounds like a good idea . I wrote about it for the SuccessFactors book, so I can look again at this.

For the Job Profile, you cannot see it from the "employee view" typically.

[Former Member]

Luke, and two last questions:

1. If I choose for JPB position based model do I need EC licences or only Foundation

2. If it's normal that I can't see near employee's job code the link to job profile how can I make it visible (so the employee can see his job profile).

Many, many thanks!!!

[lukemarson]

1. You don't need EC, the Metadata Framework is part of Foundation (aka Platform).

2. You could create a Configuration UI for the Job Profile object and add it in Employee Files

[Former Member]

Hi Luke; We have been documenting the differences between EC and Succession Position management. I wonder if that would be helpful here. What do you think? 

[lukemarson]

Hi Margaret,

That could make a great blog topic.

All the best,

Luke

[Former Member]

Thanks Luke. I will do that!

[UlrichRhomberg]

Hi Luke,

thanks for sharing this great blog. Is there any customer facing document available for position management (with EC)? Our customer wants to prepare for our Workshop.

I checked your Link to SAP Marketplace - unfortunatly the Link is broken. I can´t find the workbook - only the Implemenation guide. Is there any update on the workbook?

https://websmp109.sap-ag.de/~sapidb/012002523100008179942014E/PositionMgmt_Impl.pdf

Thanks

Ulrich

[lukemarson]

Hi Ulrich,

The implementation guide is the only customer facing guide. There is no workbook, although the Position object definition is included in the Foundation Objects workbook.

Best regards,

Luke

[Former Member]

This is a really helpful article. Thank you for all your effort on this.

[Former Member]

Thank you Luke!

[former_member27286]

Hi Luke, This is a great article. Thank you... I have 1 question as I read this. Will be thankful if you can respond please.

In one of the article on SCN, I read - "If you implement Position Management in SF, you Cannot add new employee without having a position to link employee to" - It means that if you choose to activate & implement Position Management - it needs to be implemented for all the employees in the organization - The system does not provide you the choice to activate/ implement it and use it for only few employees in the organization (Partial Position Management is not possible in SuccessFactors). Could you pl confirm on this.

As some organizations may want to do Succession Planning only for top executives and would really want Position Management for those positions/ top exec's only.

Will SuccessFactors Position Management support this "Partial Position Management" functionality.

Thanks in advance..

Kirti

[#47]

Hi Kirti! As for now, position can be non-mandatory field in jobinfo. - so there are no limitations on your requirements, but "implicit" position management can be also the case.

[Former Member]

Hi Luke,

Great blog.

Do job relationships (Matrix Managers) can be handled during hire with SYNC rule.i tried may ways the SYNC is not happening.Is it the system behavior or Config issue.The same changes i see happening when i change position data from Position chart,

Please find my rule below.

[lukemarson]

Sync of matrix job relationships is hard-coded in the system and cannot be used in the sync rule.

[Former Member]

Hi Luke,

I have a query, I am implementing position management and I want Hiring Managers (Job Requisition creators) should be able to create job requisition only for their department. Can we restrict this through RBP?

[lukemarson]

Hi Poonam,

It is possible to restrict the Positions based on a field on the Position (e.g. Department). You would need to setup a role for each Hiring Manager and hard-code the Department in the target population for the position. This role could just contain the create requisition in position org chart permission.

Best regards,

Luke