Contingent workforce management position object customization
With the emergence of the “gig economy”, most companies are relying on the use of contract workers to supplement their workforce and save money. SuccessFactors Contingent Workforce Management functionality provides a consolidated data base to easily track these workers.
Unlike a regular employee’s profile, the Contingent Worker profile only consists of a few supported portlets such as Biographical Information, Employment Details Information, Personal Information, Job information, Email Information, Phone Information, Address Information, National Id Information and Job Relationships. Contingent Workforce Management affords you the ability to limit fields while using a different Contingent Worker user interface (UI) in Manage Business Configuration. The main difference between a regular employee’s profile and a Contingent Worker’s profile is that the Contingent Workers profile has a work order portlet which usually contains the worker type, Work order ID number, Vendor information as well as pay rate information. Contingent workers, by definition, are not employees and, therefore, are not usually paid directly by the employer. Consequently, there is no need for the Compensation Portlet in their employee profile.
I have implemented Contingent Workforce Management for several Customers and for most of them their initial enquiry after the demo walkthrough is whether they can have a contingent worker specific position object since most of their already existing position fields do not apply to Contingent Workers. I spent countless hours researching on how to fulfill this requirement without creating a separate position object for contingent worker positions. Unfortunately, this research did not yield much results which is why I put this blog post together for those who have or will find themselves in a similar situation.
A Contingent Worker specific position can be achieved either through Manage Configuration UI or by the use of Field Conditions on the Position Object. The second option (use of field conditions on the position object) will be the focus of this blog post.
With position management already implemented as part of the Core HR implementation, you have the option of reusing all the position fields configured or only making limited position fields available once a particular picklist value is selected so that the limited fields will only be relevant to Contingent Workers.
For this blog post I will be showing you how to make the FTE field visible only on regular employee’s position. Since the FTE field is not relevant for Contingent Workers, it should not be visible when filling out a Contingent Worker’s position in the position org chart or in manage positions.
You can either configure a custom picklist field or use a standard picklist field on the position object in “Configure Object Definition” to build this logic. I will be creating a custom field to achieve this requirement.
- I first created a custom picklist field called “cust_employeetype” in the position object. The picklist values/labels for this field are Contractor and Employee. The picklist code for the picklist value Contractor is “cust_EmploymentType_1” whereas the picklist code for picklist value Employee is “cust_EmploymentType_2”.
- In “Configure Object Definition”, click on the details besides the field to be hidden (FTE in this case) and scroll down to the bottom of the page.
- Fill out the field id field with the code of the custom field created on the position object in this case “cust_employeetype”. In the condition value section, maintain the picklist code for employee “cust_EmploymentType_2”. What this means in effect is that, when the picklist value Employee is selected in position org chart, the FTE field should be visible. For the other fields which should only be visible when contractor is selected no values should be maintained in the field ID and condition value fields.
Once this configuration is completed, already existing positions assigned to regular employees will start showing in position org chart with only the limited fields that are only specific to Contingent Workers. To update the existing positions, go to Import and Export data and export the Regular Employees positions. Beside the position code and the newly created position field (cust_employeetype in this case), maintain all other fields as &&NO_OVERWRITE&&. Maintain the picklist code for regular employee position which in this case is cust_employmentType_2. Reimport all the Regular Employees positions back into the system via import and export data. Depending on your Position Management set up, these changes will sync over to the job information with no extra effective dated record created.
Additional customization such as defaulting this field to display as a particular picklist value at all times is also feasible. Typically, this field will with the help of a simple rule, default to Employee at all times. Role Based Permission can also be used to define who gets to edit this field and who can have view only access.
Please like, comment, share and let me know if you have any questions.
- Contingent Workforce Management Implementation Guide
- Employee Central Implementation Guide
Check out my other blog post on concurrent employment for contingent workers here.
This is a really useful blog. I haven't used field conditions this way, instead using the Config UI rules. However, as I'm sure you've discovered the Config UI rules are very buggy. I will look to use these next time.
Thanks Brandon for your comment! What I found while trying to use config UI for this requirement is that it did not allow me to save the contingent worker position since there were required fields on the position object for regular employees. In order not to set all the fields as not required (which was not ideal for my clients), this option proved to be useful. Plus, unlike config UI, this solution requires no maintenance once it is set up.
Nice work, Berlinda! This topic needed a good explanation like yours.
I have a use case for this now and hope to try this out soon.
Excellent Berlinda! You literally saved my day!
Thanks Nagesh! I am happy you found this useful!
Can you use an existing field, e.g. Employee Class, instead of creating a custom field? If so, this would eliminate need to re-import, right?
I was reading your blog and I understand that the best practice is to hide the FTE field for contingent workers. I would like to know if it is possible to enable this field and if that will have any negative impact on SF.