Steps to Take Before you Begin

Implementing the Credential Dashboard can have a transformative effect on a program. It transforms the experience from a relatively bland rendering of possibilities to an intentional representation of a person professional possibilities and aspirations. That being said, there are implementation constraints that require implementors to engage carefully with the possibilities and the changes are dramatic enough that we need carefully managed change management plans to achieve the desired impact.

Before you begin, make sure to read this entire document. It describes some of the common patterns that are available to you as well as some patterns that do not work as well or aren’t supported at all.

Because of the significant visual changes, expect the client to need to update any user guides or training materials that previously used the Learning Plan List page. This may require extensive work. Consider also communications planning for activities such as introductory webinars or recorded training to walk people through the changes.

The last section in this document has a checklist of tasks to implement the Credential Dashboard successfully.

Client Prerequisites

Clients must have the following pieces in place to implement the Practitioner Dashboard:

• All Credentials must exist in the system as Credentials

• All Applications must belong to their actual Credential

If Applications for multiple Credentials are clustered under a single Credential, create the missing Credentials and move the Applications to the appropriate Credentials.

To make the most of the Credentialing Dashboard, the client will also need the following:

• Distinct badges for each Credential - If a client does not have a distinct badge for each credential, the system will default to a default badge (a circle with a star in it). The rendering will be attractive, but visitors will not benefit from the possibility of branding.

• Descriptions for each Credential - If a client does not have distinct definitions, the system will work, but visitors will not benefit from any distinctions the program can make to differentiate one Credential from another.

The Credentialing Dashboard allows many scenarios, but is still constrained to several core options. Because there is still some functionality missing to achieve all possible scenarios, we highlight the most common / best thought-out implementation patterns and differentiate them from Unsupported Patterns so you do not commit to something the client will not accept. The Unsupported Options can be available through Innovation, we just can’t support them with 11.0 functionality.

How to write Descriptions

Now that we have both Credential descriptions and Application descriptions, we want to be more intentional about the contents of each of them. Consider the following distinctions:

Conceptual Questions

The biggest conceptual question to ask about the display is the nature of “My Credentials.” Depending upon the scenario, My Applications will either be Applications the Practitioner has started or Applications the Practitioner can start.

The primary condition for one direction or another is how many credentials exist in the program and how narrowly the program wants to focus the person on credentials they are currently pursuing. We describe the difference in these approaches as “Stay In Your Lane” vs. “Reach for the Stars.” The Stay In Your Lane model focuses on what a person currently possesses. The Reach for the Stars model opens the experience to credentials the person can start but has not yet started.

We need to be careful about these conceptual models because some system limitations prevent us from some granular definitions of what defines whether a person can start a credential. See the Unsupported Patterns for guidance on functionality we would like to have but can’t with *.0 functionality.

Supported Patterns

The distinction among Supported Patterns comes down to what we want to see in the “My Credentials” area. In the Stay In Your Lane approach, we want to focus people on the “My Credentials” because they are the credentials the person either possesses or is in process to achieve.

Labeling tabs can be tricky because they need to reflect both what the tab contains and address how the tab differentiates from other tabs. Consider the following setting patterns:

Stay In Your Lane

Use the following configuration for the Stay In Your Lane pattern. The emphasis is on promoting narrow focus on what a person has already started to do.

Unfolding Experience

In this model, the person will experience the dashboard as follows:

1. Upon first visit, the person will land on the “Other Credentials” tab because they have no applications in progress.

2. The person will be able to navigate all credentials according to whether the program exposes programs that can’t be started.

3. Once the person starts an Application for a Credential, that Credential will now display

Reach for the Stars

The Reach for the Stars pattern exposes people to more possibilities, as the emphasis is on promoting additional behavior and achievement.

Unfolding experience

1. When a person first visits, they will land on the Available Credentials tab and see:

   1. all of the Credentials that require a Role the person possesses

2. The can navigate to the Other Credentials tab to see any Credentials they cannot start

3. As soon as they obtain a Role that will allow them to start one of Credentials on the Other Credentials tab:

   1. the system will move those Credentials to the Available Credentials tab

See the Unsupported Implementation Patterns for constraints governing the concept of “Availability.”

Unsupported Implementation Patterns

As of 11.0, the Credential Dashboard has one feature gap that may cause some disappointment if not managed carefully. In the transition from an “Application-based” to a “Credential-based” model, we have not fully closed the ability to define rich criteria to start a Credential. The criteria for a Credential to be “available” is whether an Application for that Credential is available. In the LearningBuilder 11.0 Dashboard, we have three mechanisms to govern application availability, none of which is quite sufficient to manage progressive credentials.

Progressive credentials have two characteristics that are not supported by the 11.0 version of LearningBuilder: prerequisites and obsolescence. Prerequisite credentials allow a Credential to become available once one or more other credentials have been achieved. Obsolete credentials cease to become available when a person achieves other milestones.

The rules governing availability in the 11.0 experience include the following:

• A person possesses the Role necessary to complete an Application. This is not sufficient to manage progress credentials because a person possesses the Role as soon as they start a process. We have no ability to establish availability based on Role Status for anything other than the Role governing the application. We cannot, for example, make the application for a Supervisor Application dependent upon the Certificant Role Status of “Active.”

• A person possesses the Role necessary to start the Grant Role Workflow for the requisite Role. This works for situations like the Practitioner / Credential Role distinction, but does not offer enough granularity to manage progressive credentials. The permission to start a Role Grant Workflow is on the possession of a Role, not a Role Status.

• A person possesses the Role Status necessary to Start the Application. This is not sufficient to manage progressive credentials because it applies only to the Role governing an Application. We can specify that a person must possess a Role and Role Status, but that Role must be the governing Role of the Application, not another Role.

Pseudo-support for pre-requisites

None of the configuration options can enforce the business rules necessary to handle prerequisites or obsolescence. Consider the following scenario:

• We have five certifications: one foundational and four advanced. To start the certification process for an advanced certification, you must have completed the foundational certification.

• If we configure the Other Credentials tab to show available applications, the following scenario will follow:

  • Upon first visit, the person will see only one credential: the foundational credential, because it is the only one they are eligible to start.

  • Once they start the certification process, they will obtain the Foundational Credential Role.

  • Because the person now possesses the Foundational Credential Role, they are technically able to start the Advanced Credentials.

To make the most of this situation, we recommend using the “Stay In Your Lane” pattern for progressive credentials:

• Tab 1: My Credentials

• Tab 2: Other Credentials

A person will explore as follows:

1. Upon first visit, the person will arrive at the Other Credentials tab and see only one credential: the foundational credential.

2. When the person starts that credential, the following display logic applies:

   1. The Foundational Credential will always show in the My Credentials tab

   2. The Advanced Credentials will show in the Other Credentials tab

3. If a person wants to apply for the Advanced Credential, they could go to the Other Credentials tab and start the process, but they would be stopped relatively early in the process by virtue of the fact that they could not demonstrate completion of the Foundational Credential.

The Dashboard will provide some value along the lines of the “Stay In Your Lane” principles by segmenting the Advanced Credentials from the Foundational Credential. It will, however, inaccurately render the Other Credentials as available to start even when the person does not possess the pre-requisites to achieve the credential.

Pseudo support for obsolescence

The 11.0 rules similarly do not support situations in which a program is no longer of interest to a person because they have achieved a higher credential. Consider the following scenario:

• A program offers two foundational credential:

  • A fully certified person who has achieved two years of work experience

  • An apprentice who is certified to practice under the supervision of someone else but has not achieved the work experience requirement

• Once a person achieves the fully certified credential, there is no reason for them to consider applying to become an apprentice, therefore, that option ideally will be removed from view altogether.

Similarly to the configuration for pre-requisites, we recommend using a “Stay In Your Lane” configuration option. This approach correctly segments the options a person is working on from those they are not working on.

• Tab 1: My Credentials

• Tab 2: Other Credentials

This model works exceptionally well for the Apprentice pathway but less so for the Certified Pathway.

A person will explore as follows:

1. When the person first visits, they will see the Other Credentials tab with the Apprentice and Certified credentials available.

2. When the person selects the Certified credential, the following display logic applies:

   1. The Certified credential displays in My Credentials

   2. The Apprentice credential displays in the Other Credentials tab

3. The person never has to see the Apprentice designation again, but there will always be an Other tab and the Apprentice credential will always show as being “available” because the person possesses the Role necessary to start it.

Unsupported Pre-requisite rendering

The following scenario represents how we would want the system to work to support both prerequisites and obsolescence:

• A program has the following configuration:

  • An Apprentice Certification

  • A Foundational Certification

  • Two Advanced Certifications

We would expect the system to behave as follows:

1. When a person logs on, they see the following:

   1. Available Certifications

      1. Apprentice Certification

      2. Foundational Certification

2. When a person selects Apprentice Certification, we would expect the following:

   1. The Foundational Certification moves to My Certifications

   2. The Apprentice Certification Stays in “Available Certifications” because if a person can’t quite make the Foundational, they may reverse course and try for Apprentice at a later point.

3. Once a person achieves the status of Active Foundational Certification, the following would happen:

   1. The Apprentice Certification would disappear from “Available Certifications” because a person would never become an Apprentice from the Foundational status

   2. The Advanced Certifications would appear in the “Available Certifications” tab because the person is now eligible to start them.

We are in the process of designing functionality to support this scenario, but it does not exist as of 11.0. we are eager for a customer to sponsor the functional gap, but we have no deadline for that functionality in the existing road map (As of 12/2021).

Implementation Checklist

The following checklist provides rough level of effort should clients ask Heuristics to perform various tasks. Those with HS / Client can be performed by either party.