Forty templates that should be four
A new variant gets created every time a clause or a region differs. Conditional content would collapse the set, but nobody built it that way and now every change means forty edits.
Conga · Custom Development
When Conga cannot do it out of the box.
Conga's configuration surface is wider than most teams ever use — and it does have an edge. Twopir Consulting finds that edge for each requirement, then builds past it only where building is genuinely required: advanced templates, cross-object queries, Apex, Lightning components, embedded experiences. Half this job is telling you which requirements need no code at all.
Trusted by 500+ organizations — including teams who were told their requirement was impossible, and teams who were quoted code for something configuration covers.
Development Coverage
- Salesforce Partner
- Advanced Templates
- Conga Queries
- Apex
- Lightning Web Components
- Experience Cloud
- Solution Refactoring
- Code Review
"Conga can't do that" is usually not true
It is usually "nobody here knows how", which is a different problem with a much cheaper fix. These six are what we are actually called in for.
The data is three objects away
The document needs related records, a rollup and a filtered child list. Standard merge fields reach one hop; nobody knew a Conga Query could reach the rest, so the numbers get pasted in by hand.
Apex was written for something configuration does
A previous developer solved a routing problem in code because it was faster for them than learning the parameter that already does it. Now it is a maintenance liability nobody wants to touch.
Customers need the document and cannot log in
Generation works beautifully for internal users. The requirement is a customer in a portal producing their own certificate or statement, and that genuinely is past the configuration surface.
The merge is slow and getting slower
Queries pull every field on every related record because that was easiest to write. At a hundred records nobody noticed; at ten thousand the button times out.
The customisation has no owner and no documentation
It works, nobody knows how, and the person who wrote it has gone. Every change request becomes a research project before it becomes an estimate.
Where configuration ends and code begins
Conga customization is the work of extending Conga past what its configuration surface can express. The first job is establishing whether your requirement is actually past it — and for most requirements, it is not. Here is the test we apply.
| The requirement | Verdict | Why |
|---|---|---|
| Content changes by region, product or tier | Configuration | Conditional content in one template handles variation. Duplicating templates per variant is the expensive way to do it. |
| Data from several related objects | Configuration | Salesforce reports and Conga Queries pull cross-object data, related lists and nested hierarchies without code. |
| Different behaviour from different buttons | Configuration | Parameters set per launch point. One solution can behave differently depending on where it was started from. |
| No interface at all for the user | Configuration | Background execution hides the output choices entirely, with the administrator pre-defining them in the solution. |
| Calculation or branching Conga cannot express | Custom code | Once the logic exceeds what declarative tools state, it belongs in Apex — written bulk-safe and governor-aware. |
| Generation inside a customer-facing portal | Custom code | An interface the product does not provide. This needs Lightning components and a deliberate security model. |
| A system with no connector | Custom code | API-level work. See API & integration architecture. |
| Output assembled or post-processed further | Custom code | Where the finished file needs work the product does not do — merging, splitting, stamping, routing on content. |
Why we push requirements down the list
Configuration is upgraded by the vendor, readable by your admin, and survives staff changes. Custom code is none of those things by default — it has to be maintained, regression-tested against every Salesforce release, and understood by whoever arrives next.
Code you did not need is code somebody has to maintain forever. So we classify every requirement in writing during discovery, and we will happily talk you out of a build.
Extending Conga without making it fragile
Three of these live below the boundary and three above it. Most engagements are a mix, and the mix is usually weighted further toward configuration than the client expected.
Advanced Template Engineering
Conditional sections, repeating regions, dynamic tables and nested logic — the work that collapses a sprawling template set back into a governed one.
- Conditional content and dynamic sections
- Repeating detail regions with correct dataset aliasing
- Multi-format output from one template family
- Brand and layout governance across the set
- Consolidating variant sprawl into parameters
Conga Queries & Data Sources
Getting the right data to the merge without writing code. Cross-object SOQL, related lists, filtered child records — and queries that stay fast as volumes grow.
- Cross-object and nested-hierarchy queries
- Report-versus-query selection per data set
- Query tuning for large record volumes
- Dataset aliasing and detail-region wiring
- Documented, commented query library
Solution Audit & Refactoring
Reading what exists, finding the code that configuration would replace, and simplifying without breaking anything the business depends on.
- Inventory of solutions, templates and queries
- Identifying code that configuration now covers
- Performance profiling of slow merges
- Naming, versioning and documentation standards
- Staged refactoring with regression tests
Apex Development
Where the logic genuinely exceeds declarative reach. Written bulk-safe and governor-aware to Salesforce standards, with tests, so it survives contact with real data volumes.
- Bulkified, governor-aware Apex
- Asynchronous and batch patterns where volume demands
- Test coverage that tests behaviour, not line count
- Sharing, CRUD and field-level security respected
- Configuration-driven rather than hard-coded
Lightning & Embedded Experiences
Generation surfaced where the user actually is — inside a record page, a guided flow, or a customer-facing Experience Cloud site with a security model that holds.
- Lightning Web Components around generation
- Screen Flow and guided-process embedding
- Experience Cloud and portal-facing generation
- Guest and community user security design
- Accessible, responsive component markup
Custom Output Handling
What happens to the file after it exists: assembly, splitting, stamping, conditional routing, and writing results somewhere the standard paths do not reach.
- Document assembly and post-processing
- Conditional routing based on content or record state
- Custom storage destinations and naming
- Downstream record and status updates
- Orchestration covered on automation & workflow
Custom work that the next person can read
The measure of good custom development is not that it works on day one. It is that someone else can safely change it in a year.
Classify
Every requirement goes above or below the line, in writing, with the reason. This is where we talk you out of the builds you do not need — and it is also where the estimate stops being a guess.
Exhaust configuration first
For anything near the line we prototype the configured approach before quoting the coded one. Occasionally that changes the verdict, which is always the cheaper outcome for you.
Design for volume from the start
Bulk-safe, governor-aware patterns, and queries written for the record counts you will have in three years. Most Conga performance problems are design decisions made at a hundred records.
Build, review, test
Peer-reviewed against Salesforce build standards, with tests that assert behaviour rather than chase a coverage number, and a permission pass because field-level security is the usual culprit.
Document and hand over
What it does, why it exists, what it depends on, and what would break it. Undocumented customisation is how a business ends up unable to change a field name.
What good custom work leaves behind
Legal Document Automation
Conga Composer on Salesforce · Twopir Consulting engagement
A legal team producing client-facing documents by hand from Salesforce data. The work replaced ad-hoc files with a governed template set and made Salesforce reports and queries the single data source — a configuration-first outcome rather than a code one.
The customisation that did get built was the part that genuinely needed it, and it was documented alongside the configured work rather than treated as a separate artefact.
Read the full case studyHandover standard
Every customization engagement
A written classification of every requirement and which side of the line it landed on. Commented code with tests. A documented query library. A note of what each customisation depends on and what would break it. And a named person on your side who has been walked through it.
If your admin cannot safely change it without us, we have not finished. That standard is why the documentation sits inside the estimate rather than being offered as an extra at the end.
Review a requirementA development team that argues against development
We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at larger scale.
We know the configuration surface properly
Most "impossible" requirements are configuration nobody had explored. Knowing where the real edge is takes more product depth than reaching for Apex, and it is usually the cheaper answer.
We write Salesforce code to Salesforce standards
Bulk-safe, governor-aware, security-respecting, configuration-driven rather than hard-coded. Our Conga development sits inside a Salesforce practice, so the code is reviewed as Salesforce code.
We will tell you your code should be deleted
Inherited customisation often duplicates something the product now does natively. Removing it is a real deliverable, and it reduces what you have to regression-test forever.
We design for the volumes you will have
Merge performance problems are almost always a query written when the object held a hundred records. We ask about the three-year number before writing the first one.
Documentation is part of the build
Not a phase that gets cut when the timeline tightens. Custom code without documentation is a liability you pay for every time somebody new touches it.
Answers before the first call
Apply three tests. Does the requirement need logic Conga cannot state declaratively? Does it need an interface Conga does not provide, such as generation inside a customer portal? Does it need to reach a system Conga has no connector for? If the answer to all three is no, configuration almost certainly covers it — conditional templates, Conga Queries, parameters and background execution between them handle the large majority of real requirements. We classify every requirement against those tests in writing during discovery, before any statement of work.
In our experience, usually not. The two most common cases we see are a document that varies by region or product and was being solved by duplicating templates rather than by conditional content, and data two or three objects away that standard merge fields cannot reach but a Conga Query can. Both get described as product limitations and neither is one. There are genuine limits — the boundary table on this page names them — but the first thing worth doing is checking which side of it you are actually on.
Yes, and this is one of the genuine custom-development cases. It needs a component built around generation and, more importantly, a deliberate security model: portal and guest users have a different sharing and permission profile from internal users, and generation that works for an internal admin can fail or over-expose data for a community user. We design the security model first and build the interface second, because doing it the other way round is how portals leak records.
Usually yes. Slow merges almost always trace to queries that select more than the template needs, or that were written when the object held a fraction of today's records. Tuning what the query returns, splitting an oversized template, and moving high-volume runs to a background or batch pattern normally resolve it without touching the rest of the solution. We profile first rather than rebuilding, because the cause is often a single query rather than the design as a whole.
It can, which is one of the strongest arguments for keeping requirements below the boundary wherever possible. Configuration is carried forward by the vendor; custom code is yours to maintain. Where code is genuinely needed we write it to Salesforce standards with real test coverage so that breakage surfaces in a sandbox rather than in production, and regression testing against each seasonal release is part of our support and managed services.
Yes, and it starts with reading it rather than replacing it. The audit produces an inventory of what exists, which parts are still earning their keep, which duplicate something the product now does natively, and which are genuinely fragile. Quite often the recommendation includes deleting code — inherited customisation frequently solves a problem that configuration has since absorbed, and removing it reduces what has to be regression-tested forever. You get the inventory whether or not you ask us to do the work.
Start Here
Send us the requirement everyone called impossible
Describe what the document, agreement or quote has to do that Conga apparently will not. We will tell you which side of the line it falls on, and if configuration covers it we will say so rather than quote you a build.
Serving: US | Canada | UK | UAE | Australia | New Zealand
