Conga Product Documentation

Welcome to the new doc site. Some of your old bookmarks will no longer work. Please use the search bar to find your desired topic.

Show Page Sections

Enabling Contract Document Versioning

To enable Contract Document Versioning for your org, consider the following implementation options:

  • Enable Comply System Properties for Versioning
  • Add Version-Related Merge Event Actions
  • Add the Document Version Related List to Agreement Layouts
  • Add the Document Version to Document Naming Convention

To enable Contract Document Versioning for select agreements or based on conditions (without applying versioning globally):

  • Add the Version Aware field to Agreement Layouts
  • Add Workflow Rules to make Agreements Version Aware (optional)

Configuring Comply System Properties for Versioning

Use Comply System Properties settings to enable Contract Document Versioning for agreements in your org.

  1. Navigate to Setup > Develop > Custom Settings.
  2. Click on the Manage link next to Comply System Properties.
  3. Click Edit to edit System Properties. The System Properties form is displayed.


  4. Configure the System Properties described in the following table.

    #

    Property

    Description

    1

    Enable Version Control

    Check this box to enforce a check-in/check-out policy for agreement documents. This setting must be enabled when "Enable Document Versioning" is checked.
    Note: This property existed in Contract Management versions prior to 8, so this property may already be enabled.

    2

    Enable Document Versioning

    Check this box to enable Document Versioning. All new agreement records created in your org uses Document Versioning after this setting is enabled. Enable Version Control must be enabled for Document Versioning to work properly.

    Enabling Document Versioning changes the value of the Version Aware agreement field to TRUE for all new agreements after the property is activated. The Version Aware field is a flag that tells Conga CLM to use Document Versioning for a specific record.
    Important: It is recommended that once a record is flagged as Version Aware, you do not disable this field, as versioning becomes undefined for the agreement record in question. Instead, ensure that records which should not use Document Versioning do not have the field enabled when they are created (see the section on Workflow Rules below.)

    To enable or disable Document Versioning for specific Agreement records, see To add the Version Aware field to Agreement Layouts.

    3

    Use Agreement Locks for Versioning

    Check this box to use Agreement locks for versioning instead of document-level locking:

    • If enabled, all agreement documents are locked (by the user checking out) when any one of them is checked out.
    • If disabled, only checked out documents are locked (by the user checking out) – any other agreement documents which have not yet been checked out can be checked out for editing.

    4

    Document Naming Convention

    Specify a value to apply a custom naming convention for all agreement documents at generation, check-in and signature events.

    The following attributes permitted when formulating a document naming convention are:

    • %checkintype%
    • %action%
    • %templatename%
    • %user%
    • %timestamp%
    • %version%
    • Agreement attributes such as %:Name%. Note: any variable prefixed by ':' represents a field on the Agreement object.

    If the property contains a null value (i.e., if left blank), the current default naming convention is used: %:Name%_%action%_%templatename%_%timestamp%

    Example agreement document name using the default naming convention: SOW_Regenerated_SOW ABC_2015-08-07

    5

    Document Structure FX2 For Imported Docs

    Check this box to make document structure FX2 format for all offline documents (created or imported). If not checked, all offline documents are created in the "pre-existing" format.

    Tip: This property only applies to offline agreements created from the agreement or user Home page links in Salesforce. The format of offline agreements created using X-Author for Contracts depends on user input from X-Author.

Adding Document Version in Document Naming Convention

You can append the document version to the document name by leveraging the %version% attribute of the document naming convention property.

  1. Navigate to Setup > Develop > Custom Settings and click Manage link next to Comply System Properties.
  2. Click Edit.
  3. Configure the document naming convention field value as: %:Name%_%templatename%_%timestamp%_%version%
  4. Click Save.

An example agreement document name using above setting would be: Apttus NDA_NDA_2017-05-14_1.0.0. Here the '1.0.0' appended at the end refers to the document version.

Tip:

If you have configured %version% attribute in the Document Naming Convention property but the Enable Document Versioning property is disabled, the agreement document name shall contain an empty string in place of the version attribute.

For example, if you have configured Document Naming Convention field as %:Name%_%templatename%_%timestamp%_%version%, but you have disabled Enable Document Versioning property, the generated sample agreement name shall be Apttus NDA_NDA_2017-05-14.

Tip:

To trim the third decimal and number from the document version attribute in the Document Naming Convention property, select Trim Document Version checkbox in Document Version Properties. For more details on Trim Document Version, refer to Document Version Properties.

Adding Version-Related Merge Event Actions

For Document Versioning to work properly, the picklist values for the Merge Event Action must be updated.

  1. Navigate Objectse to Setup > Create > Merge Event.
  2. Go to the Action custom field.
  3. Add the following two values to the picklist:
    • Check Out
    • Revert Check Out

    After adding values, your merge action picklist should appear as shown in the following image:



Adding the Version Aware Field to Agreement Layouts

To view Document Version details for your agreement documents, the Document Version Related List must be added to your Agreement Page Layouts. To add the Related List to your page layouts, refer to Salesforce documentation for Edit Page Layouts for Custom Objects .

Tip: The Document Version Related List is included in the default Agreement Layout included with the Apttus Contract Management package.

Adding the Version Aware Field to Agreement Layouts

The Version Aware field is a flag that tells Conga CLM if a specific record is using Document Versioning. When the Comply System Property Enable Document Versioning is enabled, the value of the Version Aware field is set to TRUE for all new agreements org-wide at the time of record creation. You can add the Version Aware flag to your Agreement layouts as a field which allows agreement editors to turn Document Versioning on or off for a specific agreement record.
Important:

It is recommended that once a record is flagged as Version Aware, you do not disable this field, as versioning becomes undefined for the agreement record in question. Instead, ensure that records which should not use Document Versioning do not have the field enabled when they are created (see the section on Workflow Rules below.)

Important Note:

To add this field to your custom Agreement layout, refer to Salesforce documentation for Edit Page Layouts for Custom Objects .

Tip: The Version Aware field is included in the default Agreement Layout included with the Apttus Contract Management package.

Making Agreements Version Aware using Workflow Rules

You can create one or more workflow rules to set the Version Aware flag value in certain records based on the value of other record fields.

  1. Create a new workflow rule for Document Versioning. See the section on Managing Workflow for assistance with setting up a Workflow Rule in Salesforce.
  2. Specify your Workflow Rule Action as a "Field Update" (the rule updates the Version Aware field).
  3. Use Apttus__APTS_Agreement__c.Apttus__VersionAware__c as the field value in your rule.

Use Case: Enabling Contract Document Versioning Globally

Use this approach when your organization wants all new agreement records to use Document Versioning automatically, without requiring per-record configuration.

  • You have System Administrator access to your user record.

Business Context: Organizations managing large volumes of agreements across multiple stakeholders need reliable version control to ensure the correct document version is always used for review, negotiation, signature, and activation. Without a structured versioning framework, agreement owners must manually identify the right document version from an undifferentiated list, increasing the risk of errors, disputes, and compliance gaps. Enabling Document Versioning globally ensures that all new agreements are automatically tracked from the moment they are created, removing ambiguity and standardizing version management across the entire organization.

Overview: This use case demonstrates how to enable Contract Document Versioning for all new agreements in your org by configuring Comply System Properties, setting Document Version Properties, updating Merge Event Actions, adding the Document Version related list and Version Aware field to Agreement layouts, and optionally appending the version number to document names.

Scenario: A system administrator needs to ensure that all new agreement records created in the org are automatically tracked using Document Versioning, without requiring individual users to configure versioning per record. The administrator enables the Enable Version Control and Enable Document Versioning properties in Comply System Properties, configures Document Version Properties to define how version numbers increment across generation, check-in, and signature events, and adds the required Merge Event Action picklist values. The administrator also adds the Document Version related list and the Version Aware field to Agreement layouts so that contract requestors, negotiators, and reviewers can view and manage version history directly from the Agreement record.

Actors and Roles:

  • System Administrator: Enables versioning system properties, configures document version properties, updates merge event actions, and adds required fields and related lists to Agreement layouts.

  • Contract Requestor: Generates, regenerates, and manages agreement documents; triggers major version increments.

  • Negotiator: Checks in documents with or without redlines using X-Author for Contracts; triggers minor version increments.

  • Reviewer: Returns reviewed documents to the negotiator; triggers revision increments.

  • CLM System: Automatically increments version numbers based on configured properties and user actions.

  1. Configure Comply System Properties for versioning.
    1. Navigate to Setup > Develop > Custom Settings .
    2. Click Manage next to Comply System Properties, then click Edit.
    3. Select the Enable Version Control checkbox.
    4. Select the Enable Document Versioning checkbox. After this property is enabled, all new agreement records created in the org use Document Versioning. The Version Aware field is automatically set to TRUE for all new agreements.
      Note: It is recommended that once a record is flagged as Version Aware, you do not disable this field, as versioning becomes undefined for that agreement record. Ensure that records which should not use Document Versioning do not have the field enabled at creation.
    5. Optionally, select Use Agreement Locks for Versioning to lock all agreement documents when any one of them is checked out. If this property is not selected, only the checked-out document is locked. Other documents in the same agreement can still be checked out independently.
    1. Click Save.
  2. Configure Document Version Properties.
    1. Navigate to Setup > Develop > Custom Settings .
    2. Click the Manage next to Document Version Properties, then click Edit .
    3. Set the Initial Version field to 1 to start document versioning from 1.0.0, or 0 to start from 0.0.0.
    4. Set the Document Regenerate field to Major or Minor to control whether regenerating a document increments the major or minor version number.
      Note: Regenerating a document with a different template than the original restarts version numbering regardless of this setting.
    5. Configure the remaining increment settings, Increment Checkin Final, Increment Checkin with Redlines , and Increment Checkin without Redlines, by specifying Major or Minor for each.
    6. Optionally, select Trim Document Version to display document versions as two-digit values (for example, 1.2 instead of 1.2.0) in the Document Naming Convention.
    7. Click Save.
  3. Add Version-Related Merge Event Actions.
    1. Navigate to Setup > Create > Objects > Merge Event .
    2. Go to the Action custom field and add the following two picklist values:
    • Check Out
    • Revert Check Out

    The Merge Event Action picklist is updated with the versioning actions required for Document Versioning to function correctly.

  4. Add Document Version related list and Version Aware field to Agreement Layouts.
    1. Add the Document Version related list to your Agreement page layouts so that users can view version details directly from the Agreement record.
      Tip: The Document Version related list is included in the default Agreement Layout in the Apttus Contract Management package. If you are using a custom layout, refer to Salesforce documentation for editing page layouts for custom objects.
    2. Add the Version Aware field to your Agreement page layouts to allow agreement editors to enable or disable Document Versioning for individual agreement records.
      Tip: The Version Aware field is included in the default Agreement Layout in the Apttus Contract Management package.
  5. Append version to Document Naming Convention (optional).
    1. Navigate to Setup > Develop > Custom Settings and click Manage next to Comply System Properties.
    2. Click Edit.
    3. In the Document Naming Convention field, enter %:Name%_%templatename%_%timestamp%_%version%.
      Note: If Enable Document Versioning is disabled while %version% is configured in the naming convention, the version attribute is replaced with an empty string in the generated document name.
    4. Click Save.

Contract Document Versioning is now enabled globally for your org. All new agreement records are automatically flagged as Version Aware, and documents are tracked with the version pattern NDA_NDA_2017-05-14_1.0.0 across generation, negotiation, and review actions. Users can view the full version history of each agreement document directly from the Document Versions related list on the Agreement record.

Use Case: Enabling Contract Document Versioning for Specific Agreement Types

This topic describes how to use a Salesforce workflow rule to enable Contract Document Versioning selectively for specific agreement types, without enabling versioning globally across your org.

  • You have completed the following steps of 'Use Case: Enabling Contract Document Versioning globally' with the exception that Enable Document Versioning in Comply System Properties is not selected:
    • Configure Comply System Properties for versioning

    • Configure Document Version Properties.

    • Add Version-Related Merge Event Actions.

    • Add Document Version related list and Version Aware field to Agreement Layouts.

  • The Version Aware field has been added to your Agreement page layouts.
  • You have access to create Workflow Rules in Salesforce.
  • The SOW record type is configured on the Agreement object.
Use this approach when your organization does not want to enable Contract Document Versioning globally, but needs versioning enforced for specific agreement types. In this example, versioning is enabled only for Statement of Work (SOW) agreements using a workflow rule that sets the Version Aware flag to true when a new SOW record is created.

Business Context

Not all agreement types in an organization carry the same versioning requirements. High-value or complex agreements such as Statements of Work may require strict document version control to ensure that every change is traceable, while simpler agreement types do not. Enabling versioning selectively — rather than globally — lets administrators apply the overhead of version tracking only where it delivers real value, keeping the experience lighter for teams working with lower-risk agreement types.

Overview

This use case demonstrates how to use a Salesforce workflow rule to automatically set the Version Aware flag to true for a specific agreement type — in this case, SOW agreements — without enabling Document Versioning globally. The workflow rule evaluates the Agreement record type at creation and applies the flag conditionally.

Scenario

A system administrator needs to enforce Document Versioning only for Statement of Work (SOW) agreements, while leaving all other agreement types unaffected. Instead of enabling versioning globally, the administrator completes the base configuration, including Comply System Properties, Document Version Properties, Merge Event Actions, and Agreement layouts, but keeps the Enable Document Versioning property disabled. The administrator then creates a Salesforce workflow rule on the Agreement object that evaluates the record type at creation and automatically sets the Version Aware flag to True only when the record type is SOW. When a contract requestor creates a new SOW agreement, the CLM system applies the flag and version tracking begins automatically. Agreements of any other record type are created without the Version Aware flag and remain unaffected by versioning controls.

Actors

  • System Administrator: Completes the base configuration from Use Case 1 (excluding global enable), adds the Version Aware field to layouts, and creates and activates the workflow rule.

  • Contract Requestor: Creates SOW agreement records; the Version Aware flag is applied automatically by the workflow rule at record creation.

  • CLM System: Evaluates the workflow rule criteria and sets the Version Aware field accordingly on new agreement records.

  1. Create a new Workflow Rule for the Agreement object.
  2. Define the rule criteria as: Agreement: Record Type equals SOW.
  3. Set the Workflow Rule Action type to Field Update and configure it to set the Version Aware field (Apttus__APTS_Agreement__c.Apttus__VersionAware__c) to True when the criteria are met.
  4. Activate the workflow rule and validate it by creating a new SOW agreement and confirming that the Version Aware field is checked.
    New SOW agreements are automatically flagged as Version Aware. Non-SOW agreements remain unaffected.
Contract Document Versioning is now enabled selectively for SOW agreements. Only agreements matching the workflow rule criteria are flagged as Version Aware. You can create additional workflow rules to apply versioning to other agreement types based on your organization's requirements.

Use Case: Suppressing Contract Document Versioning on Renewal for Non-version-aware Agreements

This topic describes how to use a Salesforce workflow rule to prevent non-version-aware agreements from being automatically upgraded to Contract Document Versioning upon renewal.

  • Contract Document Versioning is enabled globally as described in Use Case 1: Enabling Contract Document Versioning Globally. For more information, refer to Use Case: Enabling Contract Document Versioning Globally.
  • Your org. contains existing agreements that are not Version Aware. Their Version Number field value is greater than 0, indicating they were created before versioning was enabled.
  • The Version Aware field has been added to your Agreement page layouts.
  • You have access to create Workflow Rules in Salesforce.
Use this approach when Contract Document Versioning is enabled globally, but your organization has existing agreements that were created before versioning was activated and should remain non-version-aware upon renewal.

Business context: When an organization enables Contract Document Versioning globally, renewed agreements are automatically flagged as Version Aware — even if the original agreement was created before versioning was enabled and was never tracked that way. This creates an inconsistency: the renewed agreement is suddenly subject to check-in/check-out and versioning rules that the original never had, which can disrupt existing workflows and confuse users managing those renewals. A workflow rule that suppresses the Version Aware flag on renewal ensures that the behavior of non-version-aware agreements is preserved consistently across their lifecycle.

Overview: This use case demonstrates how to use a Salesforce workflow rule to automatically set the Version Aware flag to false for agreements that are renewed from non-version-aware originals. The rule uses the Agreement Version Number field — which carries a value greater than 0 on renewed records — as its criterion to identify and suppress versioning for those agreements.

Scenario: A system administrator has enabled Contract Document Versioning globally, but the org contains existing agreements that were created before versioning was activated and are not Version Aware. When a contract requestor renews one of these older agreements, the CLM system automatically sets the Version Aware flag to True on the renewed record because the global setting applies to all new records. To prevent this, the system administrator creates a workflow rule on the Agreement object that detects renewed records using the Version Number field value greater than 0 as the criterion, and sets the Version Aware flag to False, ensuring the renewed agreement remains non-version-aware and consistent with the behavior of its original record.

Actors and roles:

  • System Administrator: Creates and activates the workflow rule that suppresses the Version Aware flag on renewal for non-version-aware agreements.

  • Contract Requestor: Renews existing non-version-aware agreements; the workflow rule ensures the renewed record does not inherit versioning.

  • CLM System: Evaluates the workflow rule criteria at renewal and sets the Version Aware field to false when the conditions are met.

  1. Create a new Workflow Rule for the Agreement object.
  2. Define the rule criteria as: Agreement: Version Number GREATER than 0.

    This criterion identifies agreements renewed from pre-existing, non-version-aware records. The Version Number field carries a value greater than 0 on renewed records because it is inherited from the original agreement.

  3. Set the Workflow Rule Action type to Field Update and configure it to set the Version Aware field (Apttus__APTS_Agreement__c.Apttus__VersionAware__c) to False when the criteria are met.
  4. Activate the workflow rule and validate it by renewing an existing non-version-aware agreement and confirming that the Version Aware field is not checked on the renewed record.
    Renewed agreements originating from non-version-aware records are not automatically upgraded to versioning. Their Version Aware field remains false.
Non-version-aware agreements now remain non-version-aware upon renewal, even when Contract Document Versioning is enabled globally. This ensures that your existing agreement records are not inadvertently affected by the global versioning setting, and that versioning behavior remains consistent and predictable across both new and renewed agreements in your org.