How to use Requested and Granted Units
- Christopher Butcher
- Documentation
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. |
Activity Units vs the Requirements Model
Requested and Granted Units function very well to assign values to specific Activities at a local level. When an Applicant Requests a specific credit for an Activity, any determination of the value of that Activity is made at the local level independent of the overarching Requirements Model.
For example, if an Applicant requests 6 units for an Activity and the program agrees that the Activity is worth 6 units, that represents a complete transaction.
One of the challenges we have in LearningBuilder is that the Requirements Model may discount Requested and Granted Units based on Requirements Model Limits. The system has no way to enforce Requirements Model rules during the data entry process. For example, the system cannot prevent someone from requesting units in an Activity that will subsequently not be counted. The reason for this limitation is that the evaluation workflow process is designed to evaluate units at the local level independent of its function in the broader application. A course is worth whatever the course is worth whether or not the application will count it towards requirements.
This limitation causes some confusion in our customers and prevents some operations that might seem accessible, for example:
We cannot represent an accurate number of Requested or Granted Units on a macro level because the count of Requested or Granted Units available to count is not subject to Requirements Model limits
We have some functional design options to close this cap, including:
Expose the Requirements Model to the Activity context when the Activity data is submitted;
Store the state of Requirements Model calculations;
In the meantime, we need to reinforce that Requested and Granted Units are to be used specifically to represent the amount of credit that represents the inherent value of the Activity independent of whether the program will accept it in the context of other Activities.
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). | Store values that change in other fields. For example, if a third party verifier can reduce the number of credits awarded, store the results of the third party verifier in a separate field. Only change Requested Units if the Applicant edits the Activity and requests a new amount. |
Never update the Requested Units with itself (bear with me) | If you were to Edit the Activity and resubmit it, the Requested Units will calculate a new value based on the current value and result in yet a third value. | Keep the original entry and calculate entry as separate fields. The original entry will be in the original units and the Requested Units will be in the calculated units. |
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. | Store values that are of other currencies in extrinsic values for that currency. For example, if Requested Units are calculated based on whether a person is a primary or secondary author, capture primary or secondary author in an extrinsic field and then populate Requested Hours with the calculated results. |
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 confuses configuration and complicates maintenance. See the Obsolete uses of Requested and Granted Units below. |
|
Make sure that the Requirements Model references the correct unit for the WF step |
|
|
Make sure you keep all your numbers updated as the WF moves around the WF |
|
|
Practices that address product shortcomings
Some limitations in the Requirements Model may prompt Analysts to configure Requested Units and Granted Units differently than intended. For example, the Requirements Model is typically configured on the initial application step of a Learning Plan Complete Workflow to prevent the submission of units that do not meet minimum Requested Units. This is because the system only has the perspective of the Applicant to work with. If we follow the rules stated above, this leads to an undesirable situation, as follows:
A person requests 10 units for an Activity;
The 10 units take the person over the minimum 20 threshold;
Reviewers downgrade the units to 8 and send it back, following the rules to leave the original 10 Requested Units;
At this point, even though the person has been told the additional 2 points do not count, the Requirements Model will still show the person as having enough credits because their Requested Units will still be above the minimum
A proposal from some Analysts is to do the following:
Store the value of Requested Units as Granted Units until the system reaches a disposition. (Requested Units = Granted Units upon submission)
Use Granted Units as the unit of measurement for the Requirements Model
In this case, when a reviewer sends the application back, configuration will have followed all stated rules:
Requested Units will not have changed
The application cannot be submitted until the minimum number of credits has been achieved
The problem with this approach is primarily that we are communicating Granted Units before we actually grant credit.
For implementations that face this problem, we will consider a configuration that follows this pattern to be within an acceptable use.
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.