Scenario Background:


A new employee has been hired, and they need to activate an institutional credential (netid, or the like).

Scenario Assumptions:


This scenario assumes that the user is being enrolled through the institutional HR system. The flow through Guest Registration and Invited / Sponsored Accounts should be similar.


Scenario Walkthrough:

  1. The employee's demographic and job data is entered into the institutional HR system.
  2. An institutionally defined process invokes the Person Registration service through REST API (synchronous) or a message in the Person Update Queue (asynchronous).
  3. Person Update invokes Person Search to determine if the person already exists in the Entity Register. We will assume that the person does not, and a new person is created.
  4. Person Update invokes Unique Identifier Creation, which generates a new Registry Identifier and an activation key.
  5. Person update stores the demographic and role data in the Master Person Store and calls the Group Update service, either via API or via messaging.
  6. The Group Update service calculates group memberships and adds the user to the appropriate dynamic groups.
  7. The user completes an institutionally defined identity proofing process, possibly including the Registry Identifier and / or activation keys generated in step #4.
  8. After identity proofing, the user initiates a Request-Based Provisioning workflow to create a new credential. This Request-Based Workflow is associated with an automatic approval, but requires that the user exist in an 'eligible for credential' group and not in an 'already activated credential' group.
  9. The Request-Based provisioning workflow executes a set of institutionally defined steps to create the necessary accounts.
  10. The Request-Based provisioning workflow invokes the Person Registration and Update service (via API or messaging) to inform the Entity Registry of any relevant identifiers resulting from the provisioning operation (e.g. username, eppn, UID/GID, etc).
  11. The Request-Based provisioning workflow invokes the Group Update service to inform the Groups service of any new group memberships the user should have as a result of the provisioning operation (e.g. 'activated users').