Member Roles
Overview
Roles are used to represent several different things:
An operational role that the user plays within the system, such as Administrator or Reviewer
A Credential that the user has obtained
A program that an organization has submitted for Accreditation (see Multi-Instance Roles)
Managing Roles
Roles are managed via Admin → Roles.
Member Roles
A "Member Role" is the intersection between a Member and a Role. It represents that the Member "has" the Role.
Member Roles are managed by Workflows that define the data properties that will be tracked. The Workflows also describe the process for granting the Role, as well as for editing an existing Member Role.
Member Roles are never fully disassociated a person once the relationship been made. Instead, Member Roles may be granted or ungranted. The Member Role record is considered ungranted until the Is Granted field set to true. The Is Granted value will default to null, so the Granting Workflow must set the Is Granted value to true when the Grant workflow completes successfully. A person who "has" a Role can be in any one of many states:
Grant Workflow not started
Grant Workflow started but not completed, and therefore the Is Granted not set to true
Grant Workflow completed, but Grant Workflow mis-configured to fail to set Is Granted to true
Is Granted set to false through some other behavior, including the Edit Role workflow
Member Types
A role can be configured to support two different member types:
Person
Organization
Role Types
A role can be configured to support two different role types:
Member
Staff
Key attributes of a Role
The following components are typically part of a Role:
Configuration setting | Details |
|---|---|
Role Type | There are two types of Roles:
|
Member Type | For a Member-type Role, this identifies whether the Role is granted to individual people or to organizations. |
Status List | The Custom List to use for the Role Status dropdown for Member Roles using this Role. |
Unique Identifiers | This is a way to distinguish one person's credential from another. By placing the Unique Identifier on the Role, we allow a person to have a different Unique Identifier for each credential the person possesses. We manage the Unique Identifier in the Role Definition. We can incorporate a variety of masks to differentiate one credential from another. A common pattern is to include the initials of the credential in the first few characters followed by 0s and the incremental number. Number increments are set in the database. Sets the pattern used when assigning Member Role Unique Identifiers |
Assignment Type | Specifies whether this is a single-instance or multi-instance Role |
Allow Deletion by User | Specifies whether or not the owner of a Member Role is allowed to delete that Member Role. This can be useful in situations where users have started a Role by accident and do not want it junking up their account. |
Is Granted | This field is a Boolean value that describes whether the person currently. |
Begin Date | This field is used to indicate when the person first obtained the Role. |
End Date | This field is used to indicate when the person no longer possesses the Role. |
Configuration Best Practices
The following configurations have proven to be especially important:
Set Is Granted to true using a Behavior on the Complete Successfully Action Grant Workflow (SR: This happens automagically and is not required; at one point in the past we did this because the automagic was broken.).
Set Begin Date to the [[Current Date]] using a Behavior on the Complete Successfully Action on the Grant Workflow.
Relabel Begin Date to "Initial Application Date" or some other label that explains the field.
Relabel End Date to "Expire Date" or some other label that explains the field in context.
Ensure the Is Granted field is not visible on the Grant Workflow except to Administrators.
Set the Is Granted field to visible to System Administrators on the Edit workflow.
Set all of the Administrative fields (Is Granted, Begin Date, End Date, etc.) on the Edit Workflow to editable only to Administrators.
Add all of the Administrative fields to the Entity View
In many cases, it is important to add a field called Credential Begin Date to reflect the date the credential was granted. This practice ensures that the Profile reflects a person certification status.
Where there is a Credential Begin Date it will also be worthwhile to include a Credential Expiration Date and a Last Renewal Date to capture next and previous steps.