Global HR Resource Search Enhancement

Hello,

Is anyone else experiencing difficulty searching and matching resource IDs in Global HR? Our HR Processing team has difficulty finding related IDs for contractors and students where we do not store an SSN. The current hire form only verifies that a new ID is not created when an existing ID already has the same SSN. We would like functionality to return possible matches based on name and other personal information like phone, email and address and give our Processors easily accessible information to make a decision and prevent duplicate IDs for the same person.

Please endorse enhancement request 109473 for this enhanced search and matching process: https://mingle-portal.us2.prd3.inforcloudsuite.com/v2/CONCIERGE_PRD/?LogicalId=lid://infor.cxp.1&Tab=ERS&ERId=109473

If anyone has advice on how you are currently handling this, I would enjoy hearing about it.

Thank you!

Find more posts tagged with

Comments

Chad Dirst

The current Resource search from allows users to search by Name and could be configured to add additional search parameters (i.e. email)

However, that only works if employees follow the process to search before creating the actual Hire. To solve that, you can configure the HireResource action to either add "confirmation required" or "cannot be entered" statements. The first warns the users and requires them to confirm they still wish to move forward while the latter provides a hard stop.

Its likely you would need to build relationships to make these edits but feasible to fulfil your requirement. Here's a couple of examples and you just need to build out the actual condition

Within the parameter rules

if (XYZ)

confirmation required

"EmployeeNameAlreadyExistsForEmployee:<XYZRel.Employee>"

if (XYZ)

cannot be entered

"EmployeeEmailAlreadyExistsForEmployee:<XYZRel.Employee>"

reaganr

Hi Chad,

Thanks for the suggestions and providing an example of what the code would look like!

michael-anastasia

We struggle with this, too, particularly when it comes to candidates who are/were in GHR as contractors who are now being hired as paid employees. While the delivered product looks for matching SSNs by default and it would be nice to allow configurable matching options (80% match between 'these' five fields, for example), we were able to get around it by creating a few custom Relations and Fields:

1. Create a Relation between Employee and JobApplication:

JobAppPossibleDuplicateEmployeeRel

one-to-many relation to Employee

Field Mapping uses ByName

related.HROrganization = HROrganization

related.Name.FamilyName = Candidate.Name.FamilyName

related.Name.GivenName = Candidate.Name.GivenName

Instance Selection

where (related.Birthdate = EEOCategories.Birthdate)

2. Create a derived Field to reference that Relation:

JobApplication is a BusinessClass

owned by Recruiting

Derived Fields

DerivedPossibleDuplicate is a DerivedField

type is Alpha size 100

if (first JobAppPossibleDuplicateEmployeeRel exists)

return ("Possible existing Employee or NPR: " + first JobAppPossibleDuplicateEmployeeRel.Employee + ". If it's the same person, use Rehire button!")

3. We then add this derived Field to the Hire form such that, if the external candidate's job application meets the conditions set in #1 (where Name and DOB match), it displays a Possible Rehire message to the recruiter.

They can still get past it in case it's not the same person, but this at least helps them visualize that unless it's a "John Smith" type of name or the contractor's name and DOB are also wrong on the existing profile, it's very likely that we already have a profile for them so the Rehire action is needed, not Hire. If you wanted to match on something other than Name/DOB, you'd just define that in your Relation's Instance Selection. Hoping this helps in the meantime!

reaganr

Hi Michael, this is really helpful! Thanks for providing such detail.

Copyright © 2025 Infor. All rights reserved.