· tutorials · 3 min read

How to Deploy Conga Composer Data with Salesforce CLI

Use SFDMU and the SF CLI to deploy Conga Composer configurations to any org in 1 command.

Use SFDMU and the SF CLI to deploy Conga Composer configurations to any org in 1 command.

The popular document merging tool Conga Composer is present in many Salesforce implementations. But deploying changes between environments can be a disaster.

Today, I am going to show you, how to deploy any Conga Composer configuration from a sandbox to production, in only one command.

*Note: Nicolas Vuillamy wrote a great article on deploying Conga Data using sfdx-hardis. His article was used as a base for this article.

How Conga Composer Works

Conga composer uses metadata, like buttons to trigger document merging on pages.

Additionally, records inside the following objects are used to merge documents:

  • APXTConga4__Conga_Template__c
  • APXTConga4__Conga_Merge_Query__c
  • APXTConga4__Conga_Email_Template__c
  • APXTConga4__Conga_Solution__c

Then, on the APXTConga4__Conga_Template__c record, there are files that are used to select the document template to merge. The latest files uploaded is used as the template.

Why Can’t We Use Change Sets?

While it would be nice to use change sets, or a CI/CD process to push Conga data to / from production, this is not possible with standard tools. Conga’s reliance of data as metadata makes standard tooling ineffective.

Thankfully, we can use data importing software to shore up this weakness. Using the free data importing tool SFDMU, we can import all the required records with one simple script.

SFDMU works by grabbing data from one org based on a configuration file, then importing it into a different org. The magic of SFDMU is that record relationships are sorted out automatically.

Configuring SFDMU

Setting up SFDMU is as simple as:

  1. Install the SF CLI
  2. Install the SFDMU plugin as follows:
sf plugins install sfdmu

Then to use the plugin, we need to create a few files.

Creating the export.json File

We need to create a file, export.json that will store the configuration of how data will be exported and imported.

{
  "objects": [
    {
      "query": "SELECT all FROM APXTConga4__Conga_Template__c",
      "operation": "Upsert",
      "externalId": "APXTConga4__Key__c"
    }
  ]
}

This works by:

  • objects Select which objects that will be exported
  • query Define how the data from the source org will be exported
  • operation How the data will be imported to the target org e.g. upsert or insert
  • externalId How to match data in the source org

*NOTE: The externalId is using the APXTConga4__Key__c, which is a unique key attached to each record. This is the best method of referencing Conga records inside buttons and in the data export process.

Because we also need to get the files associated with the APXTConga4__Conga_Template__c records, we can use the export files module to get files associated with the Conga Templates. The updated export.json file looks like this:

{
  "objects": [
    {
      "query": "SELECT all FROM APXTConga4__Conga_Template__c",
      "operation": "Upsert",
      "externalId": "APXTConga4__Key__c",
      "afterAddons": [
        {
          "module": "core:ExportFiles",
          "args": {
            "operation": "Upsert",
            "contentDocumentLinkOrderBy": "ContentDocument.CreatedDate DESC"
          }
        }
      ]
    }
  ]
}

Adding the afterAddons allows us to specify:

  • module of the export files
  • contentDocumentLinkOrderBy Order how the files are sorted, so the order of files are preserved.

Now it’s time to add the rest of the required objects. The complete export.json file looks like this:

{
  "objects": [
    {
      "query": "SELECT all FROM APXTConga4__Conga_Template__c",
      "operation": "Upsert",
      "externalId": "APXTConga4__Key__c",
      "afterAddons": [
        {
          "module": "core:ExportFiles",
          "args": {
            "operation": "Upsert",
            "contentDocumentLinkOrderBy": "ContentDocument.CreatedDate DESC"
          }
        }
      ]
    },
    {
      "query": "SELECT all FROM APXTConga4__Conga_Merge_Query__c",
      "operation": "Upsert",
      "externalId": "APXTConga4__Key__c"
    },
    {
      "query": "SELECT all FROM APXTConga4__Conga_Email_Template__c",
      "operation": "Upsert",
      "externalId": "APXTConga4__Key__c"
    },
    {
      "query": "SELECT all FROM APXTConga4__Conga_Solution__c",
      "operation": "Upsert",
      "externalId": "Name"
    }
  ]
}

Pushing Conga Changes to Productions

We can then use the following command to bring sandbox data into production:

sf sfdmu run --sourceusername SANDBOX_ORG_NAME  --targetusername PRODUCTION_ORG_NAME

Refreshing Conga Objects for a Sandbox

And if we want to refresh the sandbox we can reverse the user names

sf sfdmu run --sourceusername PRODUCTION_ORG_NAME --targetusername SANDBOX_ORG_NAME

Full Example

If you are looking for a ready to go example, check out my new org template.

Need Our Help To Get Your Data Into Salesforce?

Join dozens of other companies by learning how you can get all your company's data in one place.

Back to Blog