1. About Offboarding

Why Is It Called “Offboarding”? Registry “Enrollment Workflows” establish the process of bringing identities into COmanage Registry. "Enrollments" can also mean adding privileges, memberships, roles, or other items to an existing person's representation within Registry. The process of unraveling enrollments can be equally complex. As a result, we recommend thinking of the opposite of "enrollment" to be "offboarding" rather than "un-enrollment".

2. The Offboarding Patterns

There are six common patterns that would necessitate offboarding based on the mode (friendly or unfriendly) and the control exhibited by the person or role being offboarded (involuntary or voluntary).

3. The Anatomy of an Expiration Policy

Each Offboarding Pattern is processed as one or more Policies or specific processes. Since offboarding is often triggered by a relationship expiration date, COmanage Registry refers to the policies related to Offboarding Patterns as "Expiration Policies".

Through these policies, we can trigger all connections to a person in your Collaboration or Organization to be disabled or to affect only a subset of those relationships. The policies could apply to just a particular privilege that the person enjoys, for example, email access, access to wikis, etc.

Expiration Policies consist of the following types of configurations

• Policy Metadata - The information that defines the name/definition and status of the Policy.
• Population - the population to whom the Policy applies. These settings are defined in the policy's Conditions.
• Triggers - The set of conditions that must be true for the Policy to apply to a specific member of the population. These settings are defined in the policy's Conditions.
• Actions - The set of actions that will occur as a result of the Policy.

3.1. Policy Metadata

Consists of

• Description of the policy. This field also serves as the Policy's name.
• Status of the Policy, either "Active" or "Suspended".

3.2. Population

Population refers to whom the policy applies. These fields are set in the "Conditions" section of the Expiration Policy specification form.

• COU: The Expiration Policy will only apply to the specified COU, a subgroup of your Collaboration/Organization. If no COU is specified, the Expiration Policy applies to anyone in the Collaboration that meets the other population or trigger conditions.
• Affiliation: The Expiration Policy will only apply to people with the specified affiliation (for example, Employee, Faculty, Student, etc). If no affiliation is specified, the Expiration Policy applies to anyone in the Collaboration that meets the other population or trigger conditions.

3.3. Triggers

The following Triggers are currently supported. These fields are set in the "Conditions" section of the Expiration Policy specification form.

CO Person Role / Sponsor status

• Status: The Expiration Policy will be triggered for people in the Population (above) that have the specified status. If this trigger is not specified, the Expiration Policy applies to all in the Population regardless of Status.
• Invalid Sponsor: If set, the Expiration Policy will be triggered for people that no longer have a Sponsor that has Active status.

Timing

The people that you have registered may have roles that have "expiration dates". These dates can be set in advance to trigger expiration policies. While timing triggers do not have to be set, they can be very useful ways to initiate actions such as changing statuses or notifying people. Timing triggers can be set in one of two ways: 

• Number of Days Before Expiration: Trigger the policy to take the configured actions at the set number of days BEFORE the expiration date.
• Number of Days After Expiration: Trigger the policy to take the configured actions at the set number of days AFTER the expiration date.

You may also control the number of times that a policy will be triggered.

• Max Execution Count: The Expiration Policy will apply no more than the specified number of times. The count will reset when something changes for the Person that could potentially change which policies may apply.

3.4. Actions

Once a policy is triggered, the following actions may be executed:

New CO Person Role attributes

• COU: Move those matching the Population and Trigger conditions to a different subsection of your Collaboration/Organization (COU) as represented in Registry
• Affiliation: Change the affiliation (for example, Employee, Faculty, Student, Alumni, etc)
• Status: Change the status of the person in your Collaboration/Organization

Change condition

• Clear Expiration: Clear the Expiration date for the person.

Notifications

Send a notification (that you specify) to one or more representatives, for example:

• Administrator(s)
• A Group of people Selected from a list of specified groups in your Collaboration
• CO Person - the person whose CO Person Role is affected
• Sponsor - the person who has sponsored the person for inclusion in the Collaboration

4. Policy Steps for Common Offboarding Patterns

Each Offboarding Pattern is processed as one or more Policies, or specific processes. Since offboarding is often triggered by a relationship expiration date, COmanage Registry refers to the policies related to Offboarding Patterns as "Expiration Policies". Below are examples of the policy steps that may be used for the common Offboarding Patterns.

4.1. Expiration Pattern

1. Prior to Valid-Through date, notifications for renewal sent to administrators and/or individual
2. Valid-Through date is reached. (This can apply both to limited term and open ended appointments (eg: in the event of a layoff). For the latter, the valid-through date is simply set once known)
3. Exit Approval
4. CO Person Role Status becomes "Expired", "Grace Period"
5. Deprovisioning occurs according to grace periods
6. CO Person Role Status becomes "Expired"

4.2. Termination

1. CO Person Role Status becomes “Terminated”.
2. Deprovisioning occurs.
3. Exit Approval.

4.3. Resignation

1. Exit Approval.
2. CO Person Role Status becomes “Resigned, Grace Period”.
3. Deprovisioning occurs according to grace periods.
4. CO Person Role Status becomes “Resigned”.

4.4. Retirement

1. Exit Approval.
2. CO Person Role Status becomes “Retired, Grace Period”.
3. Deprovisioning occurs according to grace periods.
4. CO Person Role Status becomes “Retired”. Some privileges may remain.

4.5. Leave of Absence

1. Leave Dates set.
2. Deprovisioning occurs.
3. Return date reached.
4. Re-provisioning occurs.

4.6. Desertion

Treated as either Termination or Resignation, at the discretion of the administrator.

Where to go for more information

The following resources from the COmanage Registry Technical Manual provide important details about Offboarding and Expiration Policies: