...
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 results confuses configuration and complicates maintenance. See the Obsolete uses of Requested and Granted Units below. | ||
Consider using Granted Units for 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 an 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
...