In many organizations, there is a need to support a variety of "re-hire" scenarios where an apparently new identity is a close match to existing identities. Hitachi ID Identity Express includes built-in processes to automate rehire scenarios.

Re-hire scenarios can be broken down into several types:

  1. A user is terminated and should never be re-hired/reactivated.
  2. A user leaves but may be re-hired/reactivated in the future.
  3. A user takes an extended leave and is expected to return after several months.
  4. A user changes status -- for example, a contractor becomes an employee or a student becomes a faculty member.
  5. A user appears in multiple systems of record, and multiple records should be merged into a single user profile.

The following components support re-hire detection and duplicate identity linking:

  1. Set status attributes at the time of deactivation -- for example "user may be rehired" or "user should never be allowed back."
  2. Retain enough information about the user to both identify him again in the future and examine his departure status.
  3. When onboarding new users, check to see if they are actually new entries for old users and process accordingly.
  4. When consuming data from systems of record, apply rules to match against existing identities, which may have originated on other systems of record or in manual requests.

Hitachi ID Identity Manager supports these scenarios with a number of key features:

  1. User profiles contain identity attributes, which normally include termination status.
  2. Identity attributes are subject to access controls. For example, users normally cannot see their own scheduled termination date, even if it is set before they leave.
  3. User profiles can (and should) be retained indefinitely. This is supported by the Hitachi ID Systems licensing model, which does not charge for users who are (a) gone and (b) no longer have login IDs on any integrated target system. In other words, "empty profiles" are no-cost.
  4. Onboarding requests can trigger a search for existing, similar users. This is an imprecise process and so generates a confidence score based on organization-specific rules. A close match can trigger different responses:
    1. A warning (interactive or e-mailed, depending on how the onboarding request was processed).
    2. Link the new record to an already present identity.
    3. Block the onboarding request, as there is a record indicating 'do not rehire' or similar instructions.
    4. Block the onboarding request, and invite a human stake-holder to either re-activate or expand an existing profile.
  5. Matching user profiles may be based on any combination of attributes -- for example, full name, SSN, date of birth, driver's license number, personal e-mail address, etc. Different types of matches are assigned different confidence scores.

Hitachi ID Identity Manager can be used to track identity attributes and information about the circumstances under which a user left an organization. It can then detect and block onboarding of returning users, instead prompting users to either reactivate the returning user's old profile or to halt the process, since the user in question should not be allowed back.

Return to Identity Management Concepts