Contract Data Fields should be mapped to the Universal Contract Model (UCM) fields. However, there is often a need to capture additional data points for specific contract types / industries, etc. In these cases, the UCM can be extended through the use of Custom Data Fields.
It is important to note that core functionality (e.g. workflows and reporting) will be based on the UCM data fields. To ensure that these features remain functional, it is important to extend, rather than replace the UCM with custom data fields.
- Why do you need to capture this data point? What actionable decisions will be made based on the custom data point requested?
- Is there already a field in the UCM that is similar/serves the same purpose?
- If this field was not captured, what process will not be possible anymore?
Custom fields can be grouped into 3 types:
- Single value field
- Repeating field / multi-value field
- Repeating field which is part of a group of other fields that also repeat (e.g. “Town” in the set of address related fields, where it is possible to capture multiple addresses)
In addition, custom fields are grouped in ‘Aspects’ when you create them. Aspects should be used to group related fields together as these appear grouped in the UI (when viewing contract properties).
For fields that need to repeat together (i.e. type 3 above), it is important to group these into their own aspect. If not, the UI will look horrible. Single value fields and “standalone” repeating fields can be used in any Aspects.
The best practice is to create a single “Custom Fields” aspect to list all of the type 1 and 2 category custom fields. And separate Aspects for each repeating group of fields.
- It is not possible to add fields to any UCM Aspects / Property groups
- There is a hard limit to custom fields in Core. You can create more custom fields in CLMA than is possible in Core. When designing the data model, you also need to consider which fields need populating in Core.
- By default, any custom field is not available for reporting without creating a custom ETL.
Things to avoid
- Custom fields should store data points. Not pages of text. So it’s OK to have a field for ‘Does the contract include a Force Majeure clause?’ with a ‘Yes/No’ answer. It is not OK to attempt to capture and store the whole Force Majeure clause. The ‘View all Properties’ UI is designed to hold short values.
- Do not create a custom field for every single answer to the interview questions. The set of properties is meant to give an overview of a contract. Not replace the need to read it when required.