Skip to main content
Version: 6.0

Case Manager 6.0 Upgrade: Data Type Models

One of the most significant changes in Case Manager 6 is standardization and expansion of the data customizability, the Data Type Models. In the previous versions, custom fields could be assigned a name (that was used in field lists such as the advanced search), but mostly the field customization was defined in the form customization itself. Since we do not have direct access to the finer details of the form customization this presented a problem for us in using the customized data setup more generally. The Data Type Model serves as the configuration of our data in the system which is, now with more control, used to generate the forms and field lists. This, furthermore, allowed us to offer more customizability on the field in Case Manager. The following actions should be taken or aspects be considered when a site is upgraded to version 6.

  1. Firstly, the form customization is no longer accessible from Case Manager. The form customization can only be set as part of the customization of the Data Type Model in the Configuration Tools.
  2. Field names, as set up on the form customization, are discarded during the migration. Only the name as set up in the Custom Fields section will be used in the system. You can, thus, not edit the name displayed on the form to be different from the set-up name of the field. You are however allowed to hide the field name on the form.
  3. We used to have field groups in version 5 which were used to group fields for security purposes. Fully customizable security is now supported! A client can create its own set of security rights and assign them to fields as desired. The field groups are migrated during the upgrade, but we recommend these be restructured to better describe its purpose and use in the data model.
  4. For the Case object specifically, we now support different Case Types. A case type includes a subset of fields from the Case object. Different field customizations for a single field on different case types is not supported. In other words, you cannot define a single field for different use in different case types. Field customizations are defined on the level of the case, and field inclustion is specified on the level of the case type.
  5. Per-plaintiff customizations are migrated as different Case Types. The form customizations and field availability should be confirmed for all the migrated types.
  6. Case Types also allow you to assign multiple plaintiffs to a single case type, and to change the type of case later on in the process without changing the plaintiff. Even though the per-plaintiff customizations are migrated to different case types, case types should rather be used to describe the nature and purpose of a case opposed to the plaintiff. For example, “Telephony Collection Case” rather than "ABC Telecoms Case”. That said, however, if the field requirements for the case type is specific to ABC Telecoms and no other telephony client, “ABC Telecoms Case” may be the appropriate name for the case type.
  7. A grouping of the custom fields are supported. This will not affect the form customization. Grouping makes it easier to access the correct field if there are many custom fields used on the case model by giving context to the field. Consider grouping the custom fields as necessary after the migration.
  8. Note that the standard name for a few fields changed:
    1. SSP Reference is now referred to as Account Reference. The field name is customizable should a different name be preferred.
    2. Entity Reference is by default the Debtor Reference. This may change to Customer Reference in the future, however for now it will refer to the debtor. The field name, here, is customizable as well.

Non-case objects​

  1. All objects in Case Manager now have standard customizations built into the system. Many of these objects no longer support customization by the user.
  2. Organization and Plaintiff objects are customizable since they have open fully-customizable fields. It is important to note that their default models (as migrated) do not include the financial settings fields. You should include these fields to the model after the upgrade and set the form customizations. We’ve included exported form customization files for these two objects that include the financial fields in the CaseManagerTools folder. After adding the relevant fields to the model, this form customization XML file can be imported to standardize the form for clients with financial fields included.
  3. It is possible that during the upgrade the form customization that includes the fields are already loaded, but displays empty blocks on the form where the financial fields should be. In this case you only need to add the relevant fields to the model. They will then appear as previously customized.