Roles

Roles govern how a user may interact with the system. Some Roles are pre-defined, such as Administrator, and have specific meaning to LearningBuilder. Other Roles are custom to a specific implementation and have meaning to the credentialing program itself, such as Reviewer or Board Administrator.

Roles may also represent specific Credentials that a user has earned.

Common Examples

Examples of common Roles include:

• Administrator, for managing a LearningBuilder implementation
• Reviewer, responsible for reviewing applications submitted by Practitioners
• Specific credentials, representing that the Practitioner possesses that credential

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

Common Components of a Role

The following components are typically part of a Role:

• Unique Identifier: 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.
• 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.