Skip to main content



Coupa Success Portal

Data for Contract Management


The following sections also relate to data. Please consider the holistic data requirement when designing the data model:

Data for Contract Management can be thought of as the data you see when you navigate to a contract, and data required by the system to enable certain features to work, e.g. workflow. The former will always be visible data points whilst the latter could be either visible or invisible, depending on the need.

The data points will primarily be based on the Universal Contract Model (UCM), but should not be confused with the Data for Contract Generation.

Scoping Questions

There are no scoping questions as such. Which data points will be used / need creating will be as a result of:

  • Custom Data points identified during the Metadata Workshop(s), or
  • Data points required by other features to fulfil a requirement

Design Options

The best practice is to stay within the UCM, or as close to it as possible. This ensures that the solution is as future proof as possible (as other features e.g. data extraction is based on the UCM) as well as implementing a data model that has been fully tested against all the CLMA features.

The main design options available relate to custom fields. When you create a custom model in Model Manager, the fields within will be grouped together by aspect when viewed as ‘contract properties’. As such you will want to create aspects for each group of data points. Furthermore, if a set of data points repeat together (i.e. there are multiple values for each), then such repeating groups need to be in their own aspect.

Additionally, there are two fields introduced after the UCM was created, but that are required to ensure there are no performance issues. These are the ‘Effective Date Year’ and ‘Effective Date Month’. They are required fields used in the Container Bank properties for Master and Standalone templates (but not for Order templates). Until such time that these are built into the default configuration, they need to be added for each implementation.


  1. For custom fields, do make sure every field is actually required. Each data point is another interaction the user will need to take to generate a contract (where the template does not auto-populate the value). Information displayed should inform an actionable decision / process. (e.g. ask what decision cannot be taken if this data is not present).
  2. Where different contract types each populate a different, but overlapping, dataset, consider how the aspects are created (i.e. whether the data point groupings make sense against the different data sets).
  3. For fields used to support other features (e.g. workflow), consider whether the field should be visible / invisible. For example, the DocuSign integration requires the signatory email address and names. It is useful to display the signee names. Whereas a custom workflow may want to store data against the contract to flag whether it has run once in the past. Such a field is best left hidden.

Things to avoid

Do not create custom data points for very complex clauses or every single aspect of the contract. The data points shown is to give a quick overview of the contract and should only cater to the most used information. For the details, the contract is still available and users should refer to it when needed.

  • Was this article helpful?