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.

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

Right now the mass recipient report in a scheduled report can only go to a single contact/user/lead per line of the mass recipient report. Instead, I'd like to merge a column from the mass recipient report which consists of a list of emails, maybe into the Additional To: or CC: field, like you can do with Dynamic Addresses & the field tagger in the regular DDP.

Without this, to send a single report to emails stored on our 180 chapters (custom objects), I either need to maintain 180 distribution lists and create contact records for them, or maintain 180 Scheduled Report DDPs where I hardcode the recipients and any passed values that would have been passed as !param# on the mass recipient report (and repeat for each kind of report I want to send).

Reports don't always get sent to contacts/leads/users and the passed !param that need to be sent aren't always related to a contact record, so this would give more flexibility to use the mass report and mass recipient list with custom objects.

When documents are requested via Workflow and Outbound Message, they are queued up on the servers in the order that the messages are sent (FIFO).

Where some of the requested documents are more time sensitive than others, it would be great to be able to flag to the OB Message so that the server would identify that request as high priority and generate it before the other (not high priority) documents in the queue.

A possible deliverable could be a second parallel Queue whose documents would always generate before any in the main queue allowing for FIFO on the high Priority requests as well.

The App layout (Pop up screen) when the user want to create a Document the Drawloop question do appear standard always in the English language.
In multiple Language companies this is not wished and also this questions should be showed in their own language.
It would be fine this questions could be translated by Translation WorkBench from Salesforce like you can do with fields etc.

The answer from Nintex = The Visualforce page from the screenshot cannot be currently translated. A workaround is to create your own Visualforce page or to automate the button so that the Document package, Contact and Delivery option will be automatically selected and the user will only see the progress bar.

Example of a popup screen with English question.