Rehire Scenarios

Learn more about rehire scenarios.

In many organizations, there is a need to support a variety of "re-hire" scenarios. Multiple Hitachi ID Identity Manager reference implementations include 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.

In each case, there are three components to the process:

  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.

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. A close match can trigger the onboarding request to be blocked, with a message to the requester that an existing user profile should be reactivated instead (or the onboarding in the physical world terminated, due to a 'do not rehire' flag.). Matching historical profiles may be based on name, SSN, date of birth, driver's license number, personal e-mail address, etc.
  5. The Identity Manager API includes functions that search for matching user profiles, which are needed by this type of plug-in request validation program.

The user experience with these components depends on the business process in question:

  1. A user mistakenly trying to provision a new profile for already has an inactive user profile:
    1. The request is blocked from completion.
    2. The requester will be informed either that reactivation is allowed or forbidden.
    3. The user will be notified of what profile ID to reactivate, if appropriate.

  2. There is a request form to reactivate an old profile, which may trigger creating new login accounts, mailboxes, etc. using the old profile ID.

  3. The user experience when an automated process consumes a data feed (examples: HR data or student database) which includes "re-hired" users is that these users are not automatically provisioned and instead an e-mail is sent to a human user to decide what to do in each case.

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