Outline

What is a Learning Plan a.k.a., Application?

The easiest way to think about a Learning Plan is that it is an Application. The kinds of Applications vary widely. For credentialing functions, examples include:

• Individual Initial Certification
• Individual Recertification
• Organizational Accreditation
• Organizational Annual Report
• Organizational Initial License Application
• Organizational License Renewal
• Organizational change of designated individual
• Individual change of designation status 

For non-credentialing functions, we use Applications for some of the following tasks:

• Reflective practice exercise
• Learning Plans in which there is no credentialing outcome
• Name change
• Purchase a replacement certificate
• Initiate a customer service inquiry

To do its job, an Application needs to be able to define and track many factors, including:

When the application can be worked on and by whom:

• The people and circumstances who can work on the Application
• Rules when an Application is available to start and rules governing how long the application is available

A definition of the information that needs to be provided:

• Conventions to express the requirements someone must meet to complete a successful application
• A way to enter information to be evaluated as part of the application
• Rules to prevent an Application from being submitted if it is incomplete

A process for evaluating the contents of an Application:

• A process to evaluate submitted content following submission
• A way to communicate any deficiencies to applicants
• A mechanism for Applicants to update their information so that they can address any deficiencies
• A way to reflect the status of the application to the person or organization submitting the application
• A mechanism to approve an Application
• Mechanisms to set a person's status correctly following the completion of the Application process

As you work with LearningBuilder, you will need to know how the system manages each of these areas. To define requirements and configure rules, you will need to know how changes to one part of the configuration affect other parts of the configuration. That means knowing what parts of the Application govern your requirements. 

We organize Applications into the following components:

• The Application. We call this the Learning Plan Definition because it contains all of the rules governing what a person needs to do in the Application to move it forward or back in the process.
• The Application process. We call this the Learning Plan Completion Workflow because the workflow moves the application through the organization as it is evaluated.
• Application components. We call these Activities because they represent the things people have done that prepare them for the credential they are seeking.

The following sections illustrate what parts of the system you will need to manage to meet requirements.

Parts that belong to an Application

The Application contains specific parts that govern how it works. These parts include:

• A Learning Plan Definition
• A Requirements Model
• Task Groups
• Custom Partial

The Learning Plan Definition

The Learning Plan Definition mostly describes the circumstances governing who can work on an Application when it can be worked on. That means it controls the following variables:

• The intended participant (i.e., the Member Role) and the state the Applicant needs to be in to use use this Application (i.e., the Role Status)
• When the Application is available to start (i.e., Availability Dates)
• How long a person has to complete the Application within an intended window (i.e., Cycle Dates)
• How long a person has to complete the Application in an extended window (i.e., Reporting Dates)

Application intended audience

To define who has access to the Application, we need to know a few things about a person: we need to know what credential they are pursuing and we need to know where they are in the process of pursuing that credential. In LearningBuilder, we use Member Roles to define the credential a person is pursuing. In single credential implementations, the Role accessing Applications is typically the Practitioner Role. To know where a person is in the credentialing process, we use Role Statuses. For example, a new Applicant might be in an 'Applicant' Role Status, whereas a person pursuing Recertification might be in an 'Active' or 'Certified' Role Status. For more information about Role Statuses, take a look at the articles on Member Roles.

So to determine who has access to the Application, we need the following information:

• The Role that will be using the Application to achieve personal or organizational goals ("Practitioner" for single credential Boards)
• The Role Status to use the Application. (e.g., "Applicant" for new credentials and "Active" for recertifications)

Each Application supports only one Role. They are designed to help someone achieve qualification in a particular Credential, and there is a one-to-one relationship between a Role and a Credential.

Each Application can support more than one Role Status. This allows Applicants to operate on Applications as their statuses evolve. For example:

• When someone is considered eligible to test, a program often changes the Role Status from Applicant to Candidate. We may use the same Application to track the initial eligibility process and the examination process.
• When someone fails to complete recertification requirements before their credential expires, their status may change from Active to Lapsed. Because we typically use the same Application for on-time recertification and reinstatement or late renewal, the Application needs to be able to support people with both of those Role Statuses.

When a person has access to an Application because they possess the right Member Role and Role Status, they can both start an application (if Availability Dates are correct) and complete an Application. The timing of an Application's availability and time spans is controlled by the Availability Dates and Cycle/Reporting Dates (below).

Application availability

Many credentialing programs have exam windows throughout the year. Programs with exam windows may want the Application to be available only in preparation for those windows. LearningBuilder uses the concept of Availability Dates to govern when an Application can be started.

Availability Dates do not affect the operation of an Application that has been started.

Application access

Most applications have some kind of deadline. Some are tied to specific dates, such as the end of the year, whereas others are defined relative to a person's credential date. The Application Definition needs to be able to define and track these to manage many kinds of circumstances. For example:

• Start on the date a person is certified and end a number of years later (e.g., certified on 6/1/2019 and end on 5/31/2021)
• Start on the next specified date after a person is certified (like January 1) and end on a specified date a few years later (e.g., certified on 6/1/2019; start 1/1/2020 and go through 6/30/2022)

Applications track two different date ranges: Cycle Dates, that represent when a person possesses a credential, and Reporting Dates, that represent when a person can perform tasks in the Application. Cycle Dates have no explicit impact on the functioning of the system. They provide background information for rules, but no automatic application of the rules. This is because there are many circumstances in which a person can continue to function even after a deadline. Reporting Dates, on the other hand, directly impact whether a person can perform tasks in the Application. If the date is outside the Reporting Start and End Dates, the Application will be considered Locked, and the Applicant will not be able to make any changes. These dynamics mean that Cycle Dates are less important for initial Applications than Maintenance Applications. Because an initial Applicant does not yet possess a credential, Cycle Dates do not apply. Initial Applications use Cycle Dates as a marker for deadlines. For example, the Cycle End Date may represent an early deadline while the Reporting End Date represents the final deadline. 

While Cycle Dates do not have inherent impact on the behavior of the system, they serve as important references for Application Workflows, which we discuss below. 

Advanced configuration characteristics

There are a few other aspects of an Application available for configuration, including:

• Configuration Workflows (not to be confused with Learning Plan Workflows) that define variables at the Application level
• Availability conditions
• Starting conditions

This article does not address these advanced concepts.

The Requirements Model

One of the functions of the Application is to determine when a person has met minimum requirements. The Requirements Model provides powerful tools to define quantitative requirements. The Requirements Model includes both "Requirements," defined as minimum numbers, and "Limits," defined as maximum numbers. Minimum numbers establish the quantities that must be met before the Application can move to the next step of an Application Process (a.k.a., Learning Plan Workflow). Limits define the conditions to exclude entries that exceed defined quantities. Minimum requirements tend to establish how much education and experience a person has achieved. Limits tend to weight specific kinds of activities to make sure people do not disproportionately choose easier or less important tasks.

Examples of quantitative requirements include:

• A minimum number of employment hours
• A minimum number of education hours in a particular subject
• A minimum number of procedures completed
• Passing an exam

Examples of limits include:

• Only allow a certain number of units for courses about ethics
• Only allow a number of self-reported continuing education
• Only allow a number of volunteer hours

The requirements model defines a set of conditions that must be met for an Application to be moved to a next stage in an application process. They are in conversation with the other aspects of an Application:

• Member Role attributes to make sure they apply to the right person
• Activities on the Application that represent the actions people have completed relevant to the Application (we'll talk about these later)
• The Application Workflow that governs where an Application moves next

The Requirements Model supports multiple Application Paths by maintaining dialogue with the Member Role. Requirements can be turned on or off based on Member Role Attributes. For example, a person recertifying via continuing education would want to see the quantitative requirements governing continuing education, whereas the same person pursuing recertification via exam would not want to see them. We tend to establish the relationship between Member Roles and Requirements Models by establishing Extrinsic Attribute on the Member Role to represent their Application Path. For example, we might have a Member Role Attribute called "Application Pathway" with options such as "Examination" or "Continuing Education." The Requirements Model will then show requirements related to Continuing Education when the Applicant's Member Role is "Continuing Education." 

Organize the information on the Application

Many Applications collect multiple kinds of information. Initial Applications, for example, tend to collect information about a person's academic history, professional experience, and specialized post-baccalaureate training or practice. We organize information visually in groups called Task Groups. An Application can have an unlimited number of Task Groups. The number of Task Groups typically corresponds to the number of different kinds of information to be collected.

Tasks Groups have an extensive set of characteristics to mange the application display. We organize the configuration options as follows:

• Those that affect the way the Task Group displays
• Those that affect what kinds of Activities can be added to the Task Group
• Those that affect the rules governing when a Task Group is complete 

Display attributes

Task Groups provide extensive options to control how they display. They include options for what we call the Task Group, any short and long instructions, the widths and labels of column headers, and the manner in which units display.

Activity relationships

The most important function of the Task Group is to define the kinds of Activities that can participate in the Task Group. Each Task Group determines whether to show pre-added Activities or Activities added by parties as they progress through the process. Pre-Added Activities are useful for scenarios in which a person must complete one thing and that thing is well-known. For example, if we know that a person must demonstrate completion of a specific academic degree, we can add the Academic Degree Activity to the Application definition. If, on the other hand, a person needs to demonstrate that they completed a number of credit hours across many courses, we allow Activities to be added by the Applicant.

If a Task Group allows Applicants to add Activities, the Task Group defines which Activities to allow. Task Groups can target a single Activity definition or one or more Activity Types. If the Application will collect the same kind of information for every Activity, such as an Employment record, the Task Group specifies the Activity to use and restricts access to that specific Activity. If the Task Group will accept many options, such as a variety of different kinds of continuing education Activities, the Task Group will specify the Activity Types available and the present options to the person adding the Activities.

The most important concept to remember with respect to Task Groups and Activities is that the Task Group is responsible for managing the relationship between the Learning Plan and the Activity, but does not own the Activities themselves. Activities are governed by their own definitions and workflows in dialogue with Task Groups.

Completion rules

Similar to the Requirements Model, Task Groups have rules governing when they are considered Complete. Like the Requirements Model, Task Groups can define minimums based on the number of units and the number of Activities. Unlike the Requirements Model, Task Groups do not consolidate configuration options into a single configuration window. The Requirements Model more elegantly brings together aspects of who the person is and what Activities to evaluate. Task Groups rely on the following settings:

• Task Groups count all added Activities. The way to prevent an Activity from counting in a Task Group is to make sure it cannot be added to the Task Group.
• Task Group requirements apply as long as the Task Group is visible. If you don't want a Task Group to participate in evaluating rules, you must find a way to hide it. You can hide a Task Group based on the step the Application Workflow is in and based on whether other Task Groups are complete.
• You CANNOT hide a Task Group based on Member Role Attributes the way you can with the Requirements Model.

Display information about the status of an Application

By default, an Application makes available key aspects of the Application at the top of the page. By default, the Application shows the Cycle Start and End Dates and Reporting Start and End Dates. In addition to displaying those attributes, the default view provides Administrators a means to update the Cycle and Reporting Dates. There are circumstances in which showing those dates does not communicate the right information. In those circumstances, we may introduce a Custom Learning Plan Partial to alter the contents of that area. 

In its simplest form, a Custom Learning Plan Partial can be limited to contain only the mechanism to update Cycle and Reporting Dates. In its most complex, the Custom Learning Plan Partial can be coded to include any information, including sophisticated graphics, timelines, charts, and other illustrations of progress.

One of the drawbacks of the Custom Learning Plan Partial is that the code written for the Partial applies to all Learning Plans. That means the developer needs to factor extensive information about context when defining contents. This can lead to complex and brittle code.

As with any customization effort, the Custom Learning Plan Partial requires custom code and a customer-specific code package, so is used only when other alternatives have been exhausted.

Application processes

Every Application exists in some kind of Process. Once the Application is deemed complete by virtue of the rules evaluated against Activities, the Application progresses through a series of steps for additional evaluation and processing. The mechanism that handles this process is the Application Workflow, or, more technically speaking, the Learning Plan Completion Workflow. The Application Workflow is not part of the Application. It is referenced by the Application and interacts with it to manage the Application Process.

Application Workflows are like any other Workflow except that they reference the attached Application instead of referencing an Activity. Application Workflow steps use the Workflow Editor to define fields, validation requirements, Actions, and Behaviors. Variables defined by the Application, such as Cycle and Reporting Dates, are available to the Application Workflow to guide conditional visibility and notifications. Deadline notifications are good examples of how the Application Workflow interacts with the Application. To send a deadline notification (let's say the Reporting End Date), we define a behavior on the Application Workflow relative to the Reporting End Date defined on the Application instance (for a discussion of the difference between a Learning Plan and a Learning Plan Instance, see the header below). A Behavior on a Step on the Application Workflow would be defined to trigger when the Reporting End Date of the Application instance was equal to the desired interval.

Application Tasks

Where the Application Definition defines high level requirements, the mechanism to collect information to meet requirements occurs through related Tasks, called Activities. Activities represent anything we need to collect from the Applicant to demonstrate requirements. Many Activities related to professional and academic history, such as:

• Pre-Approved Continuing Education
• Self-Reported Continuing Education
• Professional Experience
• Examinations
• Coursework
• Academic History

Some Activities are designed to collect Application-specific information or alter the course of an Application, for example:

• A pathway selector
• Instructional content for the Application
• Attestations or qualifying questions

Task Groups (see above) establish the relationship between the Application and any related Activities.

Once an Activity is added to the Application by an Applicant, details about that Activity become available to the Application. For example:

• Intrinsic and Extrinsic Attributes are available to the Requirements Model to satisfy the Requirements Model
• The Completion Status of the Activity Instance Workflow tells the Application whether it is Complete to determine how to count it
• Display Attributes on the Workflow display on the Application Display area

Learning Plan Instances

A "Learning Plan Instance" represents a specific Practitioner's application. It is "owned by", and can modify, a specific Member Role.

Related articles