Checklist Status Update Process
Last Modified: Nov 25, 2024
- 1 Overview
- 2 Getting Started
- 3 Checklist Update Parameters Page
- 3.1 Checklist Updater Instructions
- 3.2 Dry Run - Do Not Commit Changes
- 3.3 Optional Student Population Selection
- 3.4 Search Criteria and New Status
- 3.4.1 *Processing Order [REQUIRED]
- 3.4.2 *Checklist Code [REQUIRED]
- 3.4.3 Checklist Status
- 3.4.4 Item Code
- 3.4.5 Item Status
- 3.4.6 External Org ID
- 3.4.7 Current Status
- 3.4.8 *New Status [REQUIRED]
- 4 Reviewing the Log Files
- 5 Additional Notes
Overview
This guide covers the usage and impact of the custom SJ Checklist Status Update process. This enhancement allows authorized users to update statuses for checklist items based on user-defined criteria.
Getting Started
If you have access to this process, the navigation to the component is:Navigator Main Menu > SJSU Campus Solutions > Campus Community > SJ Checklist Status Updater
The landing page is the standard run control search page. Either select an existing run control value or create a new one. Like most standard processes, your settings will be saved using the specified run control.
Checklist Update Parameters Page
The main run control page to specify process parameters has several sections.
Checklist Updater Instructions
On the page itself, there are simple instructions for the basic functions of the setup and processing. For internal reference, the contents of the instructions are pulled from the Message Catalog (32101,1).
Dry Run - Do Not Commit Changes
When this checkbox is checked, the process will go through all the steps to process the run control setup parameters and select all matching students, checklists, checklist items, etc., but it will not update the checklist or checklist item tables. The selection logic used in a dry run is identical compared to a live run.
It is strongly recommended that users do a dry run and review the log files prior to proceeding with a live run.
Reviewing the log files generated from a dry run can help verify the proper selection parameters were used and the expected numbers of students, checklists, and checklist items match the values produced by the process during the dry run.
Each run of the process is technically separate, even if you use the same exact setup with and without a dry run. Because of this, there is a slight possibility that the results of the runs will differ, depending on the time elapsed between runs.
Optional Student Population Selection
The process supports the global filtering of selected students to update using delivered population selection functionality. This means that no matter what students are picked up by the checklist code (or other parameter settings), the process will limit updates to ONLY students that are matching in the population selection. This allows you to update a much more specific sub-cohort of all students with a certain checklist code/item that would otherwise not be possible with just the on-page run control parameter setup.
When the Population Selection
checkbox is checked, users can select one of three selection tools:
Equation Engine (mostly for FA)
External File (for uploading a
CSV
orTXT
file with a single column of EMPLIDs)PS Query (for using with the
SJ_CC_CL_BND
bind record, joined on EMPLID)
Pop Select by External File
If using an external file as the pop select source, it must either be a CSV
or TXT
file extension with one column of one row per EMPLID and no punctuation or quoting.
If a file extension that is not CSV
or TXT
is uploaded, the following warning will appear:
When the process runs with an uploaded file, each EMPLID will be checked to see if it’s a valid ID matching a student. If it is not, the EMPLID will be discarded. If the entire file contains invalid EMPLIDs, the process will fail to No Success
.
There is a already a defined, publicly available file mapping that should be used with any file: CHECKLIST_STUDENTS
Pop Select by PS Query
If using a query as the pop select source, it must be created with the SJ_CC_CL_BND
record as one of the selected tables with the EMPLID field bound to one or more selected records.
This record is required because it tells the pop select function which queries can be used and it also ensures that only valid EMPLIDs are selected.
The selected output fields in the query must include at a minimum EMPLID in the first column. Any additional fields are optional. There must also only be one EMPLID field selected to output in the query results.
Search Criteria and New Status
This table allows the user to specify criteria to select matching student checklist entries to be updated.
*Processing Order [REQUIRED]
This field defines the order in which the rows will be processed for updates, lowest to highest. The field is automatically populated for new rows and increments by 10. Any row can be updated and the table will re-sort when the page is saved.
The purpose of specifying a processing order is so that if one student matches across multiple rows for the same checklist and checklist item combination, the same combination will not be updated multiple times for that student. First-match-updated-only. This applies to all run-control criteria rows within the same process run.
*Checklist Code [REQUIRED]
The Checklist Code field is required because the process does not (nor should) support updating ALL possible checklists. There is also checklist code security that is obeyed such that users can only update checklists within an administrative area for which they have proper 3C Group Update Indicator security granted.
Use the icon to search within valid values. If you do not see the checklist you’re looking for, you do not have permission to update it. Users can only select valid prompt values; other values will not be accepted.
Checklist Status
The default value is Initiated
but can also be specified as Completed
or be left blank. If a status is selected, only checklists matching that status will be matched. If the dropdown is left blank, any checklist status will be matched.
Item Code
The checklist Item Code is optional and further filters down within the checklist code. If only a specific checklist item, within a group of items on a checklist, needs to be updated specify the item code.
Use the icon to search within valid values. By default, the prompt will display checklist item codes that are defined on the parent checklist in the 3C setup table but the field will accept any item code. This is in case an item code has been added to students after the checklist was created.
Item Status
The default value is Initiated
but can also be specified as another status or be left blank. If a status is selected, only checklist items matching that status will be matched. If the dropdown is left blank, any checklist item status will be matched.
External Org ID
The process supports updating only certain checklist items with an associated external org ID (separately from others within the same checklist/checklist item combination). This allows the updating of statuses for checklist items for specific colleges separately from others within the same checklist item.
For example, if De Anza and Mission Colleges are releasing final transcripts late, this process can be used to push out the Final Transcript checklist items with those external orgs associated while leaving other Final Transcript items unchanged, even if all Final Transcript items are of the same checklist item.
Use the icon to search within valid values. Users can only select valid prompt values; other values will not be accepted.
Current Status
The process supports updating only certain checklist items with an existing status (separately from others within the same checklist/checklist item combination).
For example, if two groups of the same checklists/checklist items were assigned with two separate statuses and now those two groups need to be pushed out by one month from the current status, each group can be selected separately and updated separately.
*New Status [REQUIRED]
The New Status must be specified so the process knows what date to set for checklists and checklist items.
The process automatically determines if the parent checklist for any updated checklist items needs to be updated such that the status of the checklist item is never greater than the status of the parent checklist. If the status of the parent checklist is already greater than or equal to that of each child checklist item, it will not be modified.
Reviewing the Log Files
The process generates two log files (where {ProcessInstance}
is replaced with the actual process instance number for the run):
SJ_Checklist_Update_Process_{ProcessInstance}.log
SJ_Checklist_Update_Process_ChangeDetails_{ProcessInstance}.log
Process Overview Log File
This log file contains a simple overview of the results of the process. This includes all of the run control and process instance parameters as well as informational messages about each step of the process.
Use this log file to validate the number of checklist items that will be updated for the number of distinct students.
Detailed Log File
This log file contains the details for each checklist item that was selected to update. Each row of this log file represents one individual checklist item (or checklist item and checklist) that matched the selection criteria and was to be updated.
Additional Notes
While completed checklist and completed checklist item statuses can be updated with this process, it’s necessary and will not “un-complete” or mark as
initiated
any checklist or checklist item.This process does not make any changes to the checklist or checklist item tables except for the status. No other fields are updated, including status.