Non-Employee Tracking

Hello - We did do the slimier kind of implementation. We used different “Relationship to Organization” relation for non-paid employees (contractors) . Customized the employee export flow , it marks the record as 9 but it will create a record in LT11. All contractors stay in GHR and never gets exported to S3.

We also brought in non-employees using RelationshipToOrganization. However, in V10 and V11 GHR there is a cross reference code called EmployeeFilter where you can specify true or false for each relationship. True means send to S3-Lawson, false is GHR only, no custom code needed. Keep in mind S3-Lawson will fail LT11 records that are missing key identifiers anyway, such as SSN and Birthdate. But we did not want the mess going across. We also have Jobs specific to non-employees, so we don't assign them an EEO code and they will not post.

Hello Gina - Thanks for sharing the information about EmployeeFilter . I will explore about EmployeeFilter , if it helps to remove customization.

Thanks

Hi -
What do you do in cases where a non-employee applies for a company position? Do they apply to the internal job board (since they have a resource record)? And, if you hire them, do you term their non-employee record and then rehire them as an employee (since the SS# is on both records)? Or is it considered a transfer? (Can you tell we're probably over-thinking this?)
Thanks.
Ruth Bellinger Holladay

We consider them as transfer with new Adj hire date in Landmrak. But S3 side it will be the new hire.

You can do either transfer or term/rehire in GHR.  We term for the non-employee relationship and then rehire so that GHR and S3 data are similar, and so interfaces will handle as we wish.  But either way, you will want to have a special reason code for becoming an employee and map it in the GHR Cross Reference for both Reason (as S3 Reason) and ReasonAction ( as S3 HIRE).  That is how S3 'sees' it as a hire.

Also, on the overlapping relationships.  You can have a separate work assignment for volunteer etc. but the overall person has a single relationship.  We do use the AssignmentType value to distinguish them also. As long as your non-ee work assignment is missing key attributes S3 needs, it will fail to post through.  But you will get the errors.  One option would be to create a post-approval IPA to address the exports generated by the secondary work assignment, either to delete them or flag correction/processed.  AssignmentType has attributes for include or exclude on headcount which is why we find it helpful to filter them out of reports and interfaces.

We did a pretty significant implementation of Non-Employees at the Denver Public Schools.  We utilized relationship to organization to differentiate non-employees from employees.  In cases where a person held both employee and non-employee roles, we use Employee relationship to Org and then identified the non-employee type using Job Family on the Job/Position/WorkAssignment.  We created some custom action request forms for updating non-employee specific data.  We have conditional data fields on Hire actions to require data for non-employees and make optional for regular employees.  We created an additional talent acquisition job board for posting certain non-employee positions, because we require non-employees to go through our fingerprinting process.