Narrative:
- Record is created in institutional source system.
- Institutionally defined logic invokes the Person Registration and Update service via REST API calls or by inserting Person Update messages into the Person Update queue.
- Person Registration and Update service invokes search / match to determine if the record supplied matches an existing record
- If search / match returns a definite match, person registration invokes Identifier Assignment to generate any additional identifiers (if needed), links with an existing person, address and affiliation data to Person Data Store and puts a message on the Person Update queue
- If search / match returns a possible match (verification required), Person Registration puts a message in a Person Record Verification queue, where Orchestration Engine will see it and fire a workflow. Should we define what the outcome of the workflow will be, or should that be institutionally defined?
- If search / match returns no possible match, person registration invokes Identifier Assignment to generate any needed identifiers, registers record to Person Data Store , and puts a message on the Person Update queue.
- Person Registration Service insert a Person Update message in the Person Update Queue
- Groups Service recognizes the new person message in the Person Update queue and adds group memberships based on person and affiliation data.
- Groups Service inserts group update messages into the Group Update Queue.
- Provisioning component runs rule-based provisioning based on data-driven group memberships
- Could be based on new Group Update messages in Group Update Queue
- Could also be triggered by Orchestration Engine
- Accounts and access are provisioned according to data-driven group membership
- Provisioning system may generate identifiers. If so, it will generate a Person Update message and place it in the Person Update queue
- Provisioning system may generate additional group memberships. If so, it will generate a Group Update message and place it in the Group Update queue.