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