While Mass DocGen from a report allows us to create a large number of documents at once, printing these efficiently involves a lot of babysitting.

Say you generate 2,000 documents that need to be printed and mailed. Your documents are output into the DocGen Queue. Because Lightning list views only allow the selection of 200 items, you have to repeat this process ten times:
1. Scroll DocGen Queue list view down to expose 200 or more records.
2. Select 200 records.
3. Click Download 1 PDF button to merge them into a single PDF.
4. Wait 5-6 minutes for the Nintex server to process the document merge and ready it for download.
5. Click to download the "Merged Files.pdf" document (Don't wait too long, or it will expire and be unavailable for download! Hope you were babysitting that process and didn't get distracted by something else!)
6. Move the downloaded file to a staging folder on your desktop.
7. Repeat steps 1-6

My proposal is that there is a optional checkbox on the Mass DocGen from Report screen to "Merge All Results." Upon completion of the run, Nintex's servers merge the PDFs into a single PDF (perhaps split into multiple PDFs if there is a file size consideration). When user goes to the DocGen Queue, she sees:

1. DI-00005 Merged PDF (DI-00001 - DI-00004)


2. DI-00004 Document for Marco


3. DI-00003 Document for Sally


4. DI-00002 Document for Jane


5. DI-00001 Document for John

Currently the field tags for merge documents pull the information from picklist fields directly from the list of available values in the field definition. This is problematic in an work environment where multiple languages are used for the merge documents as the merged values appear only in the one language used to define the picklist values. It is also problematic when tagging picklist fields that are populated by an external (3rd) system. At such integrations, the picklist values of a field usually contain some "abbreviations" instead of the real value. The real value of the field is displayed using translation workbench.

My suggestion: Use translation workbench values instead of the field definition values depending on the chosen language that can be defined in the DDP.

Passing credentials via Url parameters is not compatible with standard web servers, and we should always try to be compatible with standard web server behaviour when implementing web services, yes?
This would permit securing the end-point for the Http delivery option so it does not sit open to the internet as the next underground 0-day warez site. Even if there are is no way to download files once uploaded to the end-point, and even if I wrote a robot or cron job to clean up unwanted files, I should not have to write a robot to clean up unwanted files; I should just be able to secure the end-point in Apache or IIS and be done with it, like I would any other web service end-point.
Smtp delivery options already supports the fields for the username & passwd pair, so therefore this should not be a trouble with any limits on fields.

In short: please support BASIC-AUTH so I can use standard web server functionality to secure my end-point. I'm sure your security technicians will agree that an end-point which accepts anonymous uploads is a bad idea.

We currently use Drawloop with ServiceMax/Saleforce with DocuSign configured via custom button logic. This is only used on a laptop connected to a Topaz signature pad at this time.

I'm wondering if it's possible for the DocuSign offline to work together with Drawloop. Our tech's our often faced with no internet connection making it impossible for them to retrieve a signature on a DDP since the entire process must be done online in real-time. That said if ServiceMax/SF is also inaccessible then they can't do anything either.

With DocuSign offline you can sign docs, obtain signatures and initiate transactions to be used once the user is back online. I'm trying to find out if this could be leveraged along with Drawloop.

It would be great if we could obtain and retain a signature to be used later and added to the DDP once our tech's are back online.

Currently, in Drawloop, id the input pdf file for the DDP run is secured (content not available for modification), drawloop merge just throws out an error stating one or more file is password protected. As drawloop is completely handling the content related operations within salesforce package, it will be a nice to have feature to provide a placeholder to give the secured pdf file along with the password for the document so as to drawloop make the unlock the secured content and use it for merge or any other feature. This will be a great feature add for the existing DL package I presume.