Conga Composer, implemented as a system rather than a button.

In our experience the most common cause is field-level security: Composer merges what the running user is permitted to read, so a field with a perfectly good value renders blank for a user whose profile cannot see it. The next most common causes are data that was never gathered — related records need a Salesforce report or a Conga Query, since the launching record alone does not carry them — and a template field referencing a dataset alias that no query supplies. All three present identically as a blank space, which is why the template is usually the last place worth looking.

Yes, and this is where most of the real capability sits. When Composer runs from a record it gathers that record's data natively, and it can additionally take Salesforce reports and Conga Queries as data sources — which is how a document reaches related lists, cross-object data and nested hierarchies. A single solution can draw on many datasets at once, which is what makes data-heavy outputs like board packs and period summaries practical. The design question is not whether it can reach the data but selecting only what the template needs, because gathering everything is the usual cause of slow merges.

Yes — that is what background mode is for, and it is one of the most under-used settings in Composer. The administrator configures the solution with background parameters so the template choice, output format and logging behaviour are all pre-defined, and the user gets the finished document from a single click with no interface in between. Beyond saving time, it is the mechanism that makes output consistent: if every user can choose, every user eventually chooses differently, and the brand and format governance you designed stops holding.

By expressing the variation as conditions and parameters rather than as separate files. Sections that appear or disappear based on the data handle most regional, product and tier differences within one template, and parameters let the same solution behave differently depending on which button launched it. Consolidation is normally done in stages — group the near-duplicates, identify what actually differs, build one parameterised version, then retire the old set once it is proven. The benefit is not tidiness; it is that a brand or legal change becomes one edit rather than forty.

Yes, through two different mechanisms. Conga Trigger connects Composer to Salesforce automation so generation fires when conditions are met — the classic example being final paperwork produced when an opportunity is marked Closed Won. Conga Batch produces documents for many records at once and can be scheduled for a future date and time, which suits statements, renewal notices and reminders. Both need volume planning, because Salesforce API and email limits and Conga's own workflow limits all apply. We cover the design considerations on Conga automation and workflow services.

Fix, in almost every case. An old Composer deployment usually contains a great deal of accumulated knowledge about edge cases, and rebuilding discards it in exchange for an unknown set of new problems. We start with an inventory of solutions, templates and queries, establish what is sound and what is fragile, and consolidate rather than replace. The work that most often pays for itself is collapsing duplicated templates, tuning queries that have outgrown their design, and writing down what was never documented.