#Conga Composer Query3 personnes en discutent

Hi @Scott Blase

This is Conga Composer (AppExchange package) troubleshooting in scope, but different from core Apex/Flow. A few things jump out in your button before we even get to Lightning-specific causes. 

Two issues I can already see in the URL itself: 

1. &queryid= a0Lo000000JaTu4  no [Alias] prefix and no ?pv0= filter, unlike every other queryid param. That's either a leftover/duplicate or a copy-paste error — and it reuses the same ID as your [Safety] query below it, just without the alias or filter. An unaliased/unfiltered query like this can silently return the wrong (or zero) rows, or collide with the aliased dataset your template expects.
2. &TemplateGroup=Agreements-Workforce Management has an unencoded space. Classic Salesforce sometimes tolerates this in URL buttons; Lightning's stricter parameter parsing may not, which can cause params after it to be misread depending on where it falls in the string.

Since Conga confirms itself that a table not merging is a two-branch diagnosis (data-source problem vs. template problem), here's the order to check it in:

1. Open the View Data Workbook: 
2. Launch Composer from Lightning, open Tools & Settings > View Data, and check whether the table's dataset actually contains rows. If it's empty here, the problem is the data source (the Conga Query), not the template — skip straight to step 3.
3.  If data IS present, check the template's TableStart/TableEnd alias: 
4. Open the Word template and confirm the alias inside {{TableStart:Alias}} / {{TableEnd:Alias}} matches the bracketed alias on the queryid param exactly (e.g. [PerHour], [PerDay], [Safety]). A mismatch here is invisible in Classic if an older/report-based alias still happens to resolve, but breaks cleanly on Query-based Lightning setups.
5.  Fix or remove the unaliased queryid 
6. The param '&queryid= a0Lo000000JaTu4' (no alias, no pv0 filter, and reusing the same record ID as your [Safety] query) is almost certainly the culprit or at least a red flag. Give it a proper [Alias]?pv0={!Opportunity.Id} or delete it if it's leftover from an earlier version of the button. 
7.  Confirm the button is OAuth-based, not session-ID based 
8. Conga's own Lightning migration guidance requires URL buttons to be converted to OAuth buttons with Composer registered as a Connected App when moving from Classic to Lightning. If this button was carried over from Classic without that conversion, some data calls (especially secondary Conga Query calls for tables) can fail silently while the primary merge still works off the Opportunity Id alone. 
9. Check Conga Query object sharing for the Lightning running user 
10. Composer's query execution runs under the current user's sharing context. If the Conga Query (a0L) records or the underlying queried objects have sharing rules that differ for the user/profile combination used in Lightning vs Classic, the query can return zero rows for that user even though the query itself is valid.
11.  Re-test one query at a time 
12. Temporarily strip the button down to just the one queryid feeding the broken table, confirm it merges correctly, then add the others back one by one. This isolates whether it's a single bad query/alias or a systemic Lightning config issue.

On step 1 or 2 since the rest of the doc works, auth/session is probably fine, so it's most likely either that malformed queryid param (step 3) or a template alias mismatch (step 2). Start with the View Data Workbook it'll tell you in 30 seconds whether you're chasing a query problem or a template problem. 

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Hi @Monique Zimany,

This seem to be issue with conga, try to reachout to conga support for same.

https://documentation.conga.com/contract-intelligence/latest/contact-support-190354637.html

Thanks!