How to configure Conga Composer in a Salesforce Experience Site

This may be the second installment in a series of “they said it couldn’t be done!” ;P

the goal

At my job, we use Conga Composer for all of our “doc gen” [document generation] needs, which is like Mail-Merge-on-steroids. We create “printer friendly” docs with data from 5 or even 10 Salesforce objects, organized on letterhead and in beautiful tables. Our staff use Conga Composer to review information which comes in from our “Portal” (aka Experience Site). This functionality prevents staff from having to “click around” here, there, and everywhere to see the data as it is stored in Salesforce. We wanted to extend the same convenience for Partners.

Quick Vocab Note:

• Experience Site = Portal = Salesforce product fka Community Cloud
• Partner = person who has access to Experience Site (external User)
• Colleague/staff = person who has access to Salesforce (internal User)
• Conga Composer = paid app for downloading docs with mail merge content from Salesforce
• Conga Solution = one discreet bundle of instructions for a specific Merge operation
• Button = custom metadata on any standard or custom Salesforce object, which Conga utilizes for storing instructions and launching Solutions

the problem

Conga Composer is a very powerful tool and not easy to learn/configure the first time around. While I have a ton of experience using it for “internal” Salesforce users, I had never applied that learning to “external” users. The documentation on this was scant and our (amazing, very trustworthy) consultants had never done the thing I wanted to do, either.

get comfortable with Conga Composer

the licensing

The first hurdle to clear was how to give Partner Community Users access to Conga Composer, which typically is assigned one User at a time, and is fairly costly. We needed some sort of “volume based license” which simply does not exist in the Conga licensing model. To get around this, most people avoid granting individual licenses and instead use automation to request a Conga Merge (ie if I check this box, produce a Conga merge) which utilizes different permissions than *actually clicking a Conga Button.* Unfortunately, the automation style (which leverages Conga Batch, an add-on product to Conga Composer) can only deliver documents via email and it was essential to my vision to download the file immediately via the browser/user local Downloads folder.

I learned that there are “Pay Per Click” Conga units available (the official name for this is “Per Click Events” which cost about the same as the Conga Batch units. (For us, the price is $0.70 per click). Our Conga rep was not familiar with this license type – they must be rather uncommon given the way Conga is typically used at an org/company – so finding out about this was a major puzzle piece toward getting the solution built.

the build

Shoutout to Rich from Englhard Consulting who helped me clear some obstacles via community collaboration and discussion in Ohana Slack!

I started out by following the official Conga documentation on this feature, but quickly got stuck. The URL format recommended in the help documentation did not work (last checked 5/26/2023) and looks like it may be out of date due to Lightning Experience and Enhanced Domains being generally available. Here are my hard-won tips:

• Make sure you are on the latest version of Conga Composer. If you are going to put this much time into building something, you might as well get up to date ahead of time. This will also save you time with support later, although Conga claims that they do not allocate support resources to setting up Conga Solutions in Experience Sites. Boo 🙁
  
• If you are using the licensing mechanism that I recommended above, you need to grant access to Conga for all members of your Experience Site (or at least all of the members that SHOULD have access). We did this by assigning the Conga-provided Permission Set, “Composer Salesforce Community User” to all Partner Users.
  
• To customize the URL behind the Conga button for the Experience Site, I needed to go to Setup > Object Manager > [target object] > Buttons, Links, Actions and create a button “by hand.” The Conga Solution Manager has the capability to create buttons for you, but those buttons will never have the right URL for the Experience Site. Once you “fork” (aka copy and paste) the button from the Solution Manager to the custom button, you will not be able to use the Solution Manager any more to update the button. If the Experience Site button mirrors an identical Conga solution that is used internally, you will need to always make the change manually in both places.
  
• The syntax printed in the documentation is:
  • https://<community_name>.force.com/ltng/apex/APXTConga4__Conga_Composer
  • There is no need for the /ltng/ portion of the URL, and in fact, my solution did not work if it was included
• The correct (working) syntax is:
  • https://<enhanced_domain_name>.my.site.com/<community_name>/apex/APXTConga4__Conga_Composer
    
• Include the parameter, “&DS7=3” (or DS7=whatever you need it to be) in the button URL. This is called “background mode” and it ensures that the Conga solution downloads automatically (upon button press) essentially hiding the “template selection” dialogue box that we do not want external collaborators to see. (Learn more about DS7 here).

My button

Miscellaneous additional tips:

• If you are building in a Sandbox (“always test in a Sandbox yadda yadda”), make sure that you use your Sandbox Experience Site URL in the Conga button; then you will need to update the URL to the Production Experience Site when you release in Production. The button is not “dynamic” so treat it as a “hard coded” artifact in each environment.
• I ran into Template issues when I stored the Template as a “File” in Salesforce. Instead, I needed to switch back to Salesforce Classic user experience, add the Related List for Notes and Attachments to the Page Layout for Conga Templates, and upload Templates as an Attachment. No amount of finagling with File permissions and sharing access worked with Partner Users. No one at Conga could explain why this was the case, but now I know that all of the Templates referenced in Experience Site buttons must be stored as “Attachments” and not “Files.” [Files are more up to date and more powerful. Alas.]
• We have many fewer options for rendering Buttons in Experience Sites than we do in Page Layouts for internal users. While I think the Lighting Component for Conga Solutions could be used in an Experience Site Page, we wanted the buttons to be on the top of the page for easy access. Our workaround was to create a Page Layout with no fields (only buttons) and make it the default for the Experience Site User Profile for all record types. Then, we customized the Default Compact Layout for the Object. The Compact Layout and Page Layout (combined) essentially comprise the Record Banner component in Experience Sites. This allowed us to display buttons that are visible on all record pages in the Experience Site.

the results

This build has been a resounding success! Our staff, Partners (Experience Site users), and my own team+boss are delighted. We look at a quarterly report of usage statistics and we can see that Partner Users are downloading their own files frequently! This is so exciting because I believe that the data that Partners enter into the Portal should be “their” data, which they should be able to download, access, and use freely on demand. This was not possible in our prior system and getting this feature set up took a surprisingly long time with lots of unexpected pitfalls.

my invitation

If you are trying to set this up and you get stuck, please reach out to me! Or if this blog post helps you get unstuck, I would truly love to hear from you!