Configuration review tool

How our tool will change primary data items

Primary data items are the "building blocks" for configuration- case categories (CC, actually PC JIMS case types), case subtypes (CT), part types (PT), filing codes (FC), filing fees (FF), and filing components (COM).

CT and FC tab changes

Goodin has updated the PC JIMS subtype list to reflect the standards (found at We have also used the standards to update the record sheet entry codes PC JIMS has always offered for use in docketing filings. Then we set up our own Stage configuration workbook and included all of these subtypes and filing types on the CT and FC tabs. Our tool will compare the court's configuration to ours, then:

Update CMS code where we can get a full match on the description a CT/FC entry on the client’s workbook with an entry in our workbook.

  • eFileIL allows for non-standard filing codes, by setting the FC record for court use only. Our tool will not alter these in any way.

  • eFileIL does not have a mechanism for non-standard subtypes (CT records). If the court's config has CT records not in the standards, our tool will leave them in the spreadsheet.

Add entries as required

  • If any of the standard CaseCategory, CaseType or FC codes are missing from the court's configuration, we will add them. But to ensure nothing is rolled out without the court’s approval:

    • We will mark all such added CT/FC codes as not visible.

    • We will not add any entries to the CaseCategory_FilingCode tab (which controls the PC JIMS case types which allow use of the added filing code)

  • We will also add any subtypes which were in PC JIMS, but which aren't in the standards. This is required in order to e-file on a case having that subtype, because eFileIL won't allow filing on a case unless its subtype is in the configuration (as noted here). Since these subtypes aren't in the standard, they will be set to not allow case initiation.

  • We will also add a special CT record made up of each case type with an asterisk on the end (CH*, D* etc). The lack of a subtype on a case will prevent anyone from filing on the case (as noted here). But not all Goodin courts actually used subtypes. So on existing cases without subtypes, our CMS interface returns the * entry, which matches up with the * entries on the CT tab in order to allow filings (though not case initiation).

  • Filing Fee Reference Codes on existing and added records will be updated to indicate the CMS Code added to the Filing Fee table.

Consolidate the number of FC entries- in some court configurations, there are FC entries for each case type (each CC code). This is often, but not always, unnecessary. When unnecessary, we had hoped to be able to consolidate filing codes. But it turned out to be too complex a task for us to be sure we wouldn't break something in the court's configuration in the course of consolidating.

Filing fee (FF tab) changes

Filing fees vary from court to court, so neither the state nor our CMS requires a standardized list of filing fees. The fact that each court's FF Reference Codes are used in other configuration tabs is actually the reason that we can't just have each client use a Goodin "master" configuration. That said, our tool will do the following on the court’s FFs:

    • Update CMS codes- we will replace those already in the spreadsheet with a unique code which indicates both case type and amount (e.g. MR-172). This is a composite of the two pieces of data JIMS uses to select the proper fee table entry to auto-distribute a civil case payment. Using a code which includes the amount will also make it easier to verify that a new case (CT tab) or other filing (FC tab) has the right filing fee reference.

    • As noted above, any related CT and FC tab FilingFeeReference code will be updated to reflect this CMS code.

    • Consolidate duplicate FF entries. Our CMS has always automated civil filing fee distribution based on case type and amount. When the filing fee is the same for a counter-complaint as it is for a complaint, many courts still seem to have two entries in the FF tab. Our tool will consolidate such duplicates.

  • Flag FF entries which don't have a corresponding JIMS fee table entry

  • Child support admin fees- eFileIL allows filing fee items for optional services, such as certified copies. Some courts have set up an optional service item for child support admin fees. But such fees aren’t related to a filing and the money doesn’t belong in our court CMS. So there is no reason to have such a fee item in your eFileIL config.

Filing Component (COM tab)

  • Update CMS codes, when we match a court entry to the description in our workbook (which includes every component in the standards).

  • Add any of the standard COM codes which are missing, but make them not visible. No Filing Components will be added.

  • Non-standard filing components in the court's configuration will not be altered in any way.

PartyType tab

On these tabs, the court config must reflect the standardized case type and party type lists we use statewide. So will copy our configuration.


Again, the court config must reflect the standardized case type and party type lists we use statewide. So will copy our configuration.

Document Type tab

Our CMS interface uses just two codes (C/Confidential and NC/Non-Confidential). We presume that Tyler uses these same codes in all courts, so our tool will not process this tab in any way.

Flag items which were never used at all, or unusable because they weren't associated with a case type

Flag references to non-existent items

Flag Filing Fees in the eFileIL configuration which aren't in JIMS

General notes on the configuration review tool

  • Text matches will be non-case-sensitive, due to capitalization variations from court to court.

  • The Reference Codes in the configuration workbooks are normally a combination of the CMS Code and Tyler's Code ID, which varies from court to court. But in order to keep our tool simple and run it in one pass, we plan to take the data back to the way it was before the court first filled it in (no Tyler code IDs and no Reference Codes). We will then populate any Reference Code column with just our CMS code and then proceed to use that for any cross-references as well.

  • We will also try to identify cross-references which don’t exist on the primary tab (invalid foreign keys) in some way