...
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 value 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.
...
This limitation causes some confusion in our customers and prevents some operations that might seem accessible, for example:
We cannot represent and 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
...
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 in it in the context of other Activities.
...
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. |
The Relationship between Requested and Granted Units and the Requirements Model
...
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
...