This entry describes how the system intends Requested and Granted Units to be used.
Business use
Requested and Granted Units are part of the system to support a program’s ability to differentiate the amount of credit a person may want to receive from the amount the program wishes them to receive. To use these fields according to this need, the system will need to have the following business rules in place:
A review process in which a human reviewer evaluates the submission and determines whether the information submitted substantiates the credits.
A points system that unifies measurements of progress.
Definitions
Please use the following definitions when exploring the use of Requested and Granted Units.
Term | Definition |
|---|---|
Unit | This is a system-generic quantity to describe the currency a program uses to manage the value of activities in the system. Unit is almost always translated into some other label, such as “PDU,” “CEU,” “Point,” or “Credit.” The purpose of the unit is to standardize a way of measuring progress. |
Activity Unit | This is a number assigned at the Activity Definition regarding the value of a pre-defined Activity. Programs use Activity Units to specify the value of an Activity as it is used throughout the system. Activity Units are used commonly in Education Management scenarios in which the program evaluates course submissions and defines how much credit the activity awards upon completion. |
Requested Unit | A Requested Unit is the amount of credit a person wishes to receive for credit. |
Granted Unit | A Granted Unit is the amount of credit the program agrees to assign to the request. |
Practices for using Requested and Granted Units
Consider the following practices when defining the use of Requested and Granted Units:
Rule | Rationale | Alternative |
|---|---|---|
Do not adjust Requested Units in the Workflow. | We always want to know what the Applicant originally requested. If we change it, either with human action or calculated action, we will lose the original submission (other than through Audit history). | Collect the pre-calculated value in an extrinsic attribute (e.g., # weeks, # hours). Then store the results of the calculation in the Requested Units field. |
Always store Requested Units in their formal currency. | Requested Units by definition is a common currency. Using the field for something that is not of the unit will confuse the system and complicate maintenance. | Collect the pre-calculated value in an extrinsic attribute (e.g., # weeks, # hours). Then store the results of the calculation in the Requested Units field. |
Use Requested and Granted Units only for their intended purpose. | Requested and Granted Units have a special meaning in LearningBuilder. Changes to the way we use the system will confuse maintenance efforts. | Use Activity-specific attributes to collect non-standard units. Now that the Requirements Model can count units other than Requested and Granted Units, use extrinsic numeric fields that represent the scale you are tracking. For example, use a field called “Work Experience Hours” to represent the number of hours. |
If you only have one measure it is alright to use Requested Units to represent that measure. | Requested Units will still be an accurate label for the governing measure. For example, if you only care about Work Experience on an Application, it is ok to use Requested Units to represent Work Experience Hours because it serves as the “Unit” of concern. | |
If you have more than one measure, you may not equate one measure to Requested Units and another to Granted Units | Requested and Granted Units have the specific purpose to communicate what a person believed the value to be and compare it with the value the program assigns to the activity. Using terms incorrectly results confuses configuration and complicates maintenance. See the Obsolete uses of Requested and Granted Units below. |
The Relationship between Requested and Granted Units and the Requirements Model
One of the challenges we face with the current Requirements Model is that we do not currently store Requirements Model calculations. It is possible, for example, to
Obsolete uses of Requested and Granted Units
In early incarnations of LearningBuilder, we designed rules governing Learning Plan completion using only Requested and Granted Units. This limitation required us to be creative about how we used Requested and Granted Units. The most common workarounds include:
Use Requested Units for one kind of scale and Granted Units for another
Use Activity Types to differentiate one kind of unit from another
With modifications to the Requirements Model, these workarounds are unnecessary and must be at least avoided, if not remediated among early configurations.
Use Requested and Granted as different scales
Where programs tracked two different units, such as work experience hours and continuing education units, we might use Requested Units for one scale (e.g., Experience Hours) and Granted Units for the other scale (e.g., continuing education credits).
Use Activity Types to differentiate scales
To circumvent the limitations to count only Requested and Granted Units in the Requirements Model, we differentiated each scale by Activity Type. For example:
Sum of Requested Units where Activity Type = Work History must be greater than 2,000
Sum of Requested Units where Activity Type != Work History must be greater than 200
The Activity Type condition would ensure that the number of Work History hours would not satisfy the 200 hour requirement for continuing education.