Checklists
Introduction
An MFI can set up checklists that are displayed whenever users attempt to change the state of accounts. A checklist consists of a list of tasks that are required in order to change a state. A user must check each box in the checklist before the system will make the requested change.
Checklists communicate or remind the internal processes required before changing the status of accounts or customer records. Each time a user attempts changing the state of an account or customer record, the checklist defined for that state change is shown to the user. The user can read through the checklist and make sure all the requirements are met. These checklists can be associated with all workflows for accounts and client records.
Checklists are optional, and an MFI can define them for the destination states (not dependent on source states) for the following types of accounts: client, group, center, loan and savings. For example, an MFI might define a checklist for the Pending Approval state of a loan account. A user can then make sure each condition on the checklist has been satisfied before he changes the loan account to the Pending Approval state.
Note the following:
- Checklists cannot be defined for the following states: centers—Active state; groups and clients—Partial Application state.
- Checklists are not displayed during creation of client, group, center, loan, and savings accounts.
- Checklists are not attached to individual customer records or accounts, but are displayed in between state changes.
- Checklists can be modified or made inactive.
- Only the latest version of a checklist is maintained in the system. Older versions of a checklist are not maintained.
Attributes of Checklists
Checklists must be defined (through the Define new checklist link on the Admin tab) and saved, so that they can be attached to states of customer records and accounts. Attributes of checklists are provided in the following table:
| S. No. | Attribute Name | Range | Mandatory for Active/Inactive states | Can be Modified after Definition or not? | Remarks |
|---|---|---|---|---|---|
| 1 | Name | 50 char | Yes | Yes | |
| 2 | State | Active or Inactive | N/A | Yes | If the checklist is Inactive, it is not displayed in the respective state transitions. When a checklist is created, the state is Active by default. |
| 3 | Type | Client, Group, * Center, * Loans, Savings | Yes | No | |
| 4 | Displayed when moving into status | States applicable to the selected type (i.e., Client, Group, center Loans, or Savings) | Yes | Yes | Status applicable to the type selected |
| 5 | Created Date | N/A | N/A | N/A | System Generated |
| 6 | Created By | N/A | N/A | N/A | System Generated |
| 7 | Items | N/A | At least one item is mandatory. | Once specified, an item cannot be modified. But it can be deleted. | These are line items with a size limit of 250 characters per line item. There is no maximum limit on the number of items that can be included in a checklist. |
Attaching Checklists to States
The saved checklists are attached to states of accounts or customer records as per the type and state specified during creation. The specifications for the same are:
- Type: Loan; Savings; Client; Group; or Center
- Status: All statuses specific to the type. For example, a checklist can be defined for Type = Clients, and Status= Pending Approval. In this case, the checklist is displayed whenever any client record status is changed to Pending Approval. In a similar manner, a checklist can be attached to any state transition for all the types listed above.
- Exclusion: Checklists for following states cannot be defined (not required):
- Centers- Active state
- Groups and clients- Partial Application state
- Exclusion: Checklists will not be displayed during creation of a client, group, center, loan or savings account.
- On the checklist (during a state change), a ‘checkbox’ appears against each line item defined. The user can check the box if the particular line item has been satisfied.
- All items on the checklist are considered mandatory by default and they will have to be checked before the state transition is accepted by the system.
Out of Scope
- Checklists in multiple languages; however, the data model supports storing checklists in multiple languages.
- Reusing the items on checklists. Each item on a checklist has to be manually entered.
- Storing responses for checklists.