In CLMA, each contract record is associated with a single Smart Template file. However, during different statuses/actions, it is possible to have the system present a different set of questions / generate a different document. This is achieved by nesting all of the different templates into a master template group. At the group level, there is logic that determines which of the sub-templates the system needs to run at that point.
For example, the logic could contain:
If “ContractAction = CreateTransaction” AND “ContractStatus = Draft”, run the creation template for MSA, or
If “ContractAction = CreateAmendment” AND “ContractStatus = Final Pending QA”, run the capture template for an Amendment.
In addition to nesting sub-templates within the master group, it is also possible to reuse “blocks” of templates by authoring this as an XML-fragment. This makes it reusable. For example, you can author the signature block once and reuse it across all your templates.
Due to the ability to reuse components to build up the templates, it can lower the creation effort. However, by adding such components you are increasing the complexity of the template. There is a tradeoff between lowering creation effort whilst increasing complexity and making it so complex that it is too difficult to maintain.
For each transaction in a contract’s lifecycle (e.g. amendment, termination, etc.), the system is required to run the template twice. Once for the initial draft/creation and once for the ‘final capture’ step, required before that transaction can become ‘active’. (From R29, it is possible to configure per template whether the ‘final capture’ step is required.)
To cover the minimum parts of a contract’s lifecycle, it is required that you have templates that cover the following:
- Master Contract Creation
- Master Contract Capture
- Amendment (to Master) Creation
- Amendment (to Master) Capture
- Termination (to Master) Creation
- Termination (to Master) Capture
- Order Contract Creation
- Order Contract Capture
- Amendment (to Order) Creation
- Amendment (to Order) Capture
- Termination (to Order) Creation
- Termination (to Order) Capture
The recommended design is to have a common ‘Data Capture’ template, covering all transaction types for that contract. As such, only the “Creation” templates are different. This ensures the dataset being captured remains standard. Furthermore, it is recommended to reuse the same ‘Data Capture’ template across as many Contract Types (as makes sense), to facilitate reporting across the contract portfolio (as well as to reduce effort creating each template group).
Furthermore, you want to guide the design such that the Amendment and Termination creation templates can be used across different contract types. This will allow you to move to a template group design as follows:
- Master Contract Creation (unique)
- Order Contract Creation (unique)
- Amendment Contract Creation (shared across template groups)
- Termination Contract Creation (shared across template groups)
- Capture Template (caters for all contracts in template group)
There’s further templates that can be added for Recission or Supporting Documents, etc., however these are less common requirements. If these are required, then you will need to factor them in.
In addition to reusing who templates across template groups (e.g. Amendment template), it is important to also consider the reuse of certain components. Typically these are related to integrations (e.g. supplier data lookup / DocuSign integration, etc.) or common subcomponents of a contract (e.g. signature blocks or schedules, etc.)
In addition, it is also possible to use a single template to generate different variations of a contract (e.g. unilateral NDA and bilateral NDA).
When relying on a lot of reuse of templates/components, it can start to get confusing. Consider using visuals to help define the template group structure. Below is an example:
Model Implementation Template
To accelerate template development, consider using the Model Implementation Template. This template has been designed to be a pre-built working template framework, based on the best practice design mentioned above. The logic/data side of the template has been separated from the content side, to enable new content to be easily “dropped into” this template.
The idea is that for each “Creation Template”, the contract content is styled and prepared, using the variable names already defined in the logic. Once loaded into the system, it is simply referenced from this template. The “Capture Templates” are prebuilt and ready for use.
There will of course be some tweaking required based on the client’s specific requirements, however using the Model Implementation Template will save a lot of time/effort than when starting from scratch.
For more information on the Model Implementation Template, please refer to
Overall, your main consideration here is complexity vs number of templates. Where there are multiple common components, you can either have fewer templates that are complex, or more templates that are straightforward. Where customer/new resources are being trained to take up maintenance of the templates, the recommendation is always to steer towards lowering complexity.
Things to avoid
High number of variations
It is technically possible to use a single template to produce multiple contract types (e.g. Unilateral and Bi-lateral NDA), using conditions that determine what content to show/hide. This is in fact one of the key selling points of the solution. However, each additional contract type or “flavour” of contract added, adds complexity. There is a point at which there are so many types of contract in the template, where any change results in a disproportionate amount of regression testing, such that it takes too long to maintain effectively – even for minor changes. Avoid catering for more than 5 contract types/flavours within a single template. (This is not a hard limit as it depends on the number of moving parts between variations. If there’s just a single paragraph, then you can cater for a higher number of variations. If however there is a large number of moving parts (and there are different moving parts for different variations), then keep the number of variations to the lower end of the scale.)
Nesting to level n
Related to the previous item, when reusing a component, it needs to be authored as an XML-fragment. This can be considered as a mini-template. It is possible that this fragment can reference other fragments which in turn reference others still. Essentially there is no limit to the number of nesting levels that can be incorporated.
Ideally, your design should not go further than 3 or 4 levels. Example:
> Contract Template
> > Schedules / Clause Library clauses / shared components (e.g. signature blocks)
> > > Clause Library clauses within a shared component/schedules
Further than this and you risk it becoming too complex to maintain, especially if some of the lower level components are shared across template groups. Not only do you need to understand which fragments make up a template group, you also need to understand which templates would be affected if a change is made to each fragment. (The tool does not provide you this visibility, so you need to maintain such a diagram outside of the tool.)
A common requirement is for a ‘decision tree’ that determines which contract the user needs to create. This is technically achievable by adding a series of questions at the template group level, that will ultimately determine which sub-template to run. The consequence however is that you need to nest all applicable templates in this template group (including the templates for their amendments, Orders, supporting documents, etc.). This easily turns your template group into a monster of a group – resulting in the same challenge around maintenance and regression testing. Always try to have the decision around which template to run, take place outside of the template.