About Enrollment Flows
Every organization has one or more ways of bringing new people into that organization. There are a number of terms used to describe this process: application, enrollment, intake, invitation, petition, signup, etc. These processes vary significantly across organizations.
Registry has a fully customizable mechanism for representing these processes, and translating them into ways to bring people into a CO's population. These processes are known as Enrollment Flows, and the artifacts created by the execution of these processes are known as Petitions. Each CO can define as many Enrollment Flows as it needs to reflect its specific processes.
Enrollment Flows are generally intended for interactive, human driven processes. For automated, system-to-system processes, see External Identity Sources.
Enrollment Flow Actors
Enrollment Flows can have different types of participants, or Actors:
- Petitioner: The person who starts the Enrollment Flow.
- Enrollee: The person who is being enrolled (ie: the subject of the Enrollment Flow).
- Approver: The person who approves the Enrollment.
Different types of Enrollment Flows may have different Actor relationships. For example, in a self-signup flow the Petitioner and Enrollee are the same. An invitation flow might not have an Approver.
Configuring Enrollment Flows
Enrollment Flows consist of a series of one or more Enrollment Flow Steps. Enrollment Flow Steps are almost completely Plugin based, except for the start step that begins a Flow and the finalize step that ends a Flow. (These two steps are always run, and are not configured as part of the flow.) There is no conceptual difference between the Enroller Plugins that are shipped out of the box and any custom Plugins that are written for a local deployment.
New Enrollment Flows are created via Configuration > Enrollment Flows > Add a New Enrollment Flow. A few settings are configured directly on the Enrollment Flow itself:
- Petitioner Authorization: The type of Petitioner authorized to start the Flow.
- Any Authenticated User will require the Petitioner to successfully authenticate to the web server, but the Petitioner is not required to have an existing Person record in Registry. This is useful for Enrollment Flows that require an External Identity from a federated or social provider.
- None will allow anyone to start an Enrollment Flow. This is useful for Enrollment Flows that create local identities as part of the registration process. Note that flows with None authorization may be susceptible to spam enrollments, and should require approval or other steps to verify Enrollment.
- Collect Enrollee Email: If set, the Petitioner will be required to provide an email address for the Enrollee to start the Flow. This is primarily intended for invitation style enrollments, and the provided email address will be used to hand off the Flow the the Enrollee. This email address will not automatically become part of the operational Person record created for the Enrollee.
- Redirect on Finalize: When the Petition is finalized, the Actor who runs the last step will be redirected to the configured URL. This is useful to provide a "What's next?" style page with more information.
Enrollment Flow Steps
Once the initial Enrollment Flow configuration is saved, a link to Enrollment Flow Steps will become available. Each Step has some basic settings:
- Plugin: The Plugin that implements this Step. Several Plugins are enabled by default, and are listed below. Additional Plugins may need to be activated, and custom Plugins can also be written. Once the Plugin for a Step is selected, it cannot be changed.
- Order: Each Step must have a unique order value (AR-EnrollmentFlowStep-1). Steps are executed from the lowest order to the highest. If no value is provided, the next sequential order for this Enrollment Flow will be automatically inserted.
- Actor Type: The type of Actor who will complete this Step. When consecutive Steps have different Actor Types, a handoff will occur using Notifications. A Flow can switch across different Actor Types as many times as is necessary.
Additional Plugin specific configurations may be available once the Step is saved.
Note that a given Plugin can be instantiated in multiple Steps. For example, it is possible to use the AttributeCollector plugin to collect attributes from the Petitioner, and then have a later step collect additional attributes from the Enrollee.
Operational records are not created until the finalization step. This includes the overall Person record.
Available Enroller Plugins
| Plugin | Description | Available Since |
|---|---|---|
| Attribute Collector | Request attributes related to the Enrollee |
Running Enrollment Flows
Starting a Flow
The URL to start an Enrollment Flow can be found using the Start link from the Enrollment Flow configuration. This link can be used directly, eg by an Administrator, or can be sent via an appropriate channel (email, posting on a web site, etc) for self service. Starting an Enrollment Flow is subject to Petitioner Authorization, described above.
The Petition artifact is created at the end of the start step, before the first Plugin is called.
Resuming a Flow
Normally, the sequence of Enrollment Flow Steps will be executed by either redirecting the current Actor to the next Step, or sending a Notification to the appropriate Actor when the Actor Type changes. Sometimes, Petitions get "stuck", eg because an Actor didn't receive a Notification, or forgot to act on it. It is possible to resume a Petition by selecting the Resume action from the Petition list. This will show a list of all Steps within the Enrollment Flow for the Petition.
A Step that has already run can be rerun using the same mechanism. (The available actions will be Rerun for Steps that have already completed, or Continue for the next Step that has not yet run.) After a Step is rerun, the Flow will continue at the next Step that has not yet run, however this behavior is not final and may change in a future release. A Step that has not yet run (and is not the next Step to run) cannot be started early.
Keep in mind that different Steps may have different Actor Types, and so the actual process for resuming a Flow may depend on the Actor Type. For example, if the Petitioner has contacted the Helpdesk for assistance with a stuck Petition, the correct action might be for the Helpdesk agent to copy the Continue link and email it to the Enrollee, rather than click on the link themself or send it to the Petitioner.
See Also
Changes From Earlier Versions
As of Registry v5.0.0
- Enrollment Flows have been completely redesigned.
- Operational records are not updated until the Petition is finalized. Previously, operational records would be created or updated during the Enrollment Flow, even if the Flow was later rejected.
- Default Enrollment (an invitation based process used when no Enrollment Flows are defined) is no longer supported.