Manifest reference

The agreement-manager-manifest.json file defines your Agreement Manager configuration, including custom fields, custom agreement types, and extensions to standard agreement types. The Docusign CLI uses this file to configure Agreement Manager in bulk when you run the upload command.

A complete example manifest file is provided in Create a package.

Manifest properties

The following table describes the top-level properties of the manifest file.

The following example shows the top-level structure of a manifest file with abbreviated array contents:

{
  "version": "1.0.0",
  "defaultLocale": "en",
  "namespace": "com.example.manufacturing@1.0.0",
  "standardAgreementTypes": [ ... ],
  "customAgreementTypes": [ ... ],
  "fields": [ ... ],
  "metadata": {
    "createdAt": "2025-01-06T00:00:00Z",
    "updatedAt": "2025-01-06T00:00:00Z",
    "version": "1.0.0",
    "author": "Manufacturing Team",
    "description": "Custom fields for manufacturing and supplier agreements",
    "tags": ["manufacturing", "supplier", "consulting"],
    "lastManifestHash": ""
  }
}

Define custom fields

Custom fields are defined in the fields array. Each object in the array defines one custom field and its AI extraction configuration.

fields array properties

Custom field limits and constraints

• The maximum number of custom fields is 300.
• Up to 50 custom fields can have AI extraction enabled, or a combination of custom fields and custom agreement types can be used (for example, 35 custom fields and 15 custom types). No more than 15 custom agreement types can have AI extraction enabled.
• Custom field names and labels must not duplicate standard field names and labels.
• Every custom field newly defined in the manifest must be referenced in fields.customFields of at least one agreement type (standard or custom) in the manifest. This validation does not apply to fields already in the custom catalog.
• After you have added custom fields and uploaded the package, you cannot delete the custom fields from the account. If you no longer wish to use a custom field, you can remove it from any agreements that include it. See Field removal from custom agreement types and Field removal from standard agreement types.

Example custom field definition

{
  "key": "C_Subprocessor",
  "displayName": "Subprocessor",
  "fieldType": "String",
  "category": "GeneralCategory",
  "customExtractionEnabled": true,
  "aiDefinition": "The name of the third-party service provider (subprocessor) authorized to process or access customer data on behalf of the primary service provider under the agreement.",
  "examples": {
    "en": [
      {
        "exampleText": "The Service Provider may use approved subprocessors to support the delivery of services under this Agreement. As of the Effective Date, the approved Subprocessor for cloud hosting and infrastructure services is MICROSOFT AZURE.",
        "confirmedValue": "MICROSOFT AZURE"
      }
    ]
  }
}

Define custom agreement types

Custom agreement types are defined in the customAgreementTypes array. Each object in the array defines one custom agreement type, its field mappings, and its AI extraction configuration.

customAgreementTypes array properties

Custom agreement type limits and constraints

• The maximum number of custom agreement types is 200.
• No more than 15 custom agreement types can have AI extraction enabled.
• Custom agreement type names and labels must not duplicate standard agreement type names and labels.
• Training documents are required for custom agreement types with customExtractionEnabled set to true. Training documents must exist in the {workspace}/{project}/agreement-manager/files/train/ directory.
• All labels in fields.customFields must match a custom field label defined in the manifest’s fields array.

Field removal from custom agreement types

You can remove standard and custom fields from a custom agreement type by deleting them from the additionalStandardFields or customFields array. If you have previously uploaded a package that included the fields in the agreement type, you must upload again to apply the changes.

You cannot remove the default standard fields included in every custom agreement type: Title, Parties, Execution Date, Effective Date, Status, and Line of Business.

After uploading a package in which fields have been removed:

1. Test the changes.
2. Deploy the changes to your production account and any additional accounts where the field removals should be applied.
3. Reprocess any previously ingested agreements in the applicable accounts to remove the fields from the extracted agreement data.

Example custom agreement type definition

"customAgreementTypes": [
  {
    "key": "C_InternshipOfferLetter",
    "displayName": "Internship Offer Letter",
    "category": "HumanResources",
    "customExtractionEnabled": true,
    "aiDefinition": "An agreement outlining the terms and conditions of an internship, including the intern's role, start and end dates, stipend or compensation, reporting manager, and other employment terms.",
    "fields": {
      "additionalStandardFields": [],
      "customFields": ["Intern Name", "Intern Role", "Internship Start Date", "Internship End Date", "Stipend", "Reporting Manager"]
    },
    "docs": [
      "Internship Offer Letter - Charles.pdf",
      "Internship offer Letter - Bob.pdf",
      "Internship Offer Letter - John.pdf",
      "Internship offer Letter - Sarah.pdf"
    ]
  }
]

Extend standard agreement types

Standard agreement types are Agreement Manager’s out-of-the-box agreement types, each with a predefined set of standard fields. You can extend standard agreement types in the manifest by mapping additional standard fields and custom fields to them in the standardAgreementTypes array.

Use standard-catalog.json (generated by the get catalog command) as your reference when configuring standard agreement type extensions. The catalog contains the exact key and displayName values you must use, as well as the default standard fields already mapped to each type.

standardAgreementTypes array properties

Limits and constraints for extending standard agreement types

• All labels in fields.additionalStandardFields must exist in the standard catalog.

• All labels in fields.customFields must meet one of these requirements:

  • Matches a custom field label defined in the manifest’s fields array
  • Exists in the account’s custom catalog. You can use the get catalog command to retrieve the custom catalog.

• Do not add a field that is already mapped by default to the agreement type. This causes a validation error.

Field removal from standard agreement types

You can remove additional standard fields and custom fields from a standard agreement type by deleting them from the additionalStandardFields or customFields array. If you have previously uploaded a package that included the fields in the agreement type, you must upload again to apply the changes.

The default standard fields mapped to each agreement type cannot be changed or removed.

After uploading a package in which fields have been removed:

1. Test the changes.
2. Deploy the changes to your production account and any additional accounts where the field removals should be applied.
3. Reprocess any previously ingested agreements in the applicable accounts to remove the fields from the extracted agreement data.

Example standard agreement type extension

{
  "key": "ConsultingDocumentData",
  "displayName": "Consulting Agreement",
  "fields": {
    "additionalStandardFields": ["Renewal Notice Date"],
    "customFields": ["Project Code"]
  }
}

Frequently asked questions

What happens if a custom field or custom agreement type defined in the manifest already exists in Agreement Manager?

The CLI does not create a duplicate. Instead, it updates the existing field or agreement type by overwriting its properties - such as the description, category, extraction settings, or training examples - with the values defined in the manifest. Field mappings defined in the manifest are also applied to the existing agreement type.

Can I remove custom fields or custom agreement types from an account using the manifest?

No. Once a custom field or custom agreement type is added to an Agreement Manager account, the CLI cannot remove it. Standard agreement types and standard fields also cannot be removed from Agreement Manager.

Can I remove additional fields from an agreement type after they have been mapped?

Yes. To remove additional fields from an agreement type, remove the corresponding field labels from the additionalStandardFields or customFields arrays for that agreement type in the manifest, then run ds agm upload again. Note that the default standard fields mapped to each agreement type cannot be changed or removed.

What are the limits on the number of custom fields and custom agreement types with AI extraction enabled?

Up to 50 custom fields and custom agreement types combined can have AI extraction enabled. Within that limit, no more than 15 custom agreement types can have AI extraction enabled. For example, valid distributions include 50 custom fields and 0 custom types, 35 custom fields and 15 custom types, or 40 custom fields and 10 custom types. A distribution of 34 custom fields and 16 custom types is not allowed.

What manifest issues can cause validation errors when I try to upload a package?

The CLI validates the manifest before uploading and returns an error if required properties are missing or incorrect, if key or displayName values for standard agreement types do not match the standard catalog, if custom field or agreement type names conflict with standard names, if referenced training documents are missing from the agreement-manager/files/train/ directory, or if field label references in additionalStandardFields or customFields do not resolve correctly. Correct the reported issue in the manifest and run the upload command again.

Next steps

• Learn about uploading a package, including what happens after a successful upload and how to resolve validation errors.
• Test agreement customizations to validate AI extraction accuracy before deploying to production.
• Deploy agreement customizations to a production account or to multiple accounts.