A Salesforce release moves something underneath you
Solutions built around an assumption about the platform meet a platform that changed. Without regression testing in a preview sandbox, the first person to find it is a customer.
Conga · Support & Managed Services
Your Conga build works. Who keeps it working?
Salesforce ships releases through the year, templates multiply under deadline pressure, and the admin who built it eventually moves on. Twopir Consulting holds the ongoing work a live Conga deployment generates — regression testing, template governance, enablement and enhancement capacity. Including deployments we did not build, and ones nobody documented.
Trusted by 500+ organizations — including teams who inherited a Conga deployment with no documentation and nobody left who built it.
Managed Service Coverage
- Salesforce Partner
- Incident Support
- Release Regression Testing
- Template Governance
- Admin Enablement
- Licence Review
- Enhancement Capacity
- Inherited Deployments
Nothing breaks on go-live day. It breaks in month seven
A Conga deployment does not fail suddenly. It degrades — and every one of these is predictable enough to plan for. Which is the whole argument for planning for it.
The template library sprawls
A variant gets added under deadline, then another. Within a year the governed set of six is a folder of forty, nobody knows which is current, and brand consistency is gone.
The person who understood it leaves
One admin held the whole design in their head. They move on, and every change request becomes an investigation before it becomes an estimate.
Usage drifts away from what was designed
People find workarounds for the one step that annoys them, and the workaround becomes the process. The reporting still measures the designed path, so nobody sees it happening.
You are paying for licences nobody uses
Seats assigned during the rollout to people who have since changed role, and product capability you bought and never configured. Nobody owns the review, so it renews as-is.
The enhancement backlog never moves
Sensible improvements queue behind a business case for a new project, because there is no standing capacity to do small things. The system stays exactly as good as the day it launched.
Everything that happens after the project ends
Conga managed services cover the ongoing work a live deployment generates: keeping it working through platform change, keeping the template library governed, keeping people able to use it, and having capacity available when something needs to change.
Incident Support
When something stops working, a named team who already know your build picks it up — rather than a queue that starts by asking what Conga is.
- Agreed response targets by severity
- Triage across Conga and the Salesforce layer beneath
- Root-cause fixes, not repeated workarounds
- Escalation path to the vendor where needed
- Incident history you can actually review
Release Regression Testing
Salesforce ships seasonal releases, and any of them can move something a Conga solution depended on. We test in the preview sandbox before it reaches your production org.
- Preview-sandbox testing ahead of each release
- Every solution and template in the regression set
- Fixes made before production is affected
- A written note of what changed and what we did
- Conga product updates assessed the same way
Template Library Governance
Stopping the sprawl. New requirements get absorbed into the governed set through conditional content and parameters rather than by adding another near-duplicate.
- Naming, versioning and ownership conventions
- Periodic review for duplication and drift
- Brand and layout consistency checks
- Consolidating variants back into parameters
- Retiring templates nobody uses any more
Enablement & Documentation
Keeping the knowledge in your organization rather than in ours. New admins get onboarded, documentation stays current, and users get retrained when the process changes.
- Onboarding sessions for new admins
- Documentation kept current as the build changes
- Refresher training when processes change
- Office-hours access for smaller questions
- Deliberate reduction of key-person risk
Licence & Utilisation Review
What you are paying for against what is actually being used — including capability you already own and never configured, which is usually the cheapest improvement available.
- Seat assignment against actual usage
- Unused capability you have already paid for
- Volume trends ahead of renewal conversations
- Right-sizing recommendations before renewal
- Evidence to take into the vendor discussion
Retained Enhancement Capacity
A standing allocation for the improvements that never justify a project of their own — which is how a system keeps getting better instead of staying exactly as good as launch day.
- Prioritised backlog you control
- Small changes delivered inside the retainer
- Larger work quoted separately, never absorbed quietly
- Access to custom development when needed
- Regular review of what the backlog is telling you
Nobody left who built it? That is a normal starting point
A large share of the Conga deployments we support were not built by us and were not documented by anyone. Taking one on starts with reading it, and that is a defined piece of work rather than an open-ended discovery.
Inventory
Every solution, template, query, button and piece of automation, listed with what it appears to do and where it is launched from. Most clients have never seen this written down.
Assess
What is sound, what is fragile, what duplicates something the product now does natively, and what is quietly broken already. You get the assessment whether or not you continue with us.
Stabilise
Fix what is actively hurting, establish a regression set so the next Salesforce release is not a gamble, and put naming and versioning conventions in place.
Document
Write down what was only ever in somebody's head. This is the deliverable that ends the key-person risk, and it is the reason the takeover is worth doing even if nothing else changes.
Operate
Move into the standing service — or hand the documented build back to your own admin, which is a perfectly good outcome and one we scope for.
On rebuilding
The instinct with an inherited deployment is to start again. We rarely recommend it. Rebuilding discards the accumulated knowledge of edge cases that the existing build already handles, and it replaces a known set of problems with an unknown one.
Keeping what works is usually both cheaper and faster. If a rebuild really is the right answer, the inventory is what proves it — and you will have the evidence to put in front of whoever approves the budget.
Three shapes, including doing it yourself
Not every organization needs a managed service, and we would rather say so than sell one. These are the three arrangements that actually work.
| Run it in-house | Support only | Full managed service | |
|---|---|---|---|
| Right for you if | You have a capable, permanent Salesforce admin with genuine capacity. | You have an admin, but nobody to own release testing or governance. | Conga is business-critical and there is no internal owner with capacity. |
| Incidents | Your team. | Us, to agreed response targets. | Us, to agreed response targets. |
| Release regression testing | Your team — this is the one most in-house arrangements quietly skip. | Us. | Us. |
| Template governance | Your team. | Your team, with our conventions. | Us, reviewed with you. |
| Enhancement capacity | Project by project. | Quoted per change. | Standing allocation you prioritise. |
| What we do either way | Train your admin and leave full documentation. | Same. | Same — the documentation is yours regardless. |
What ongoing ownership actually looks like
Legal Document Automation
Conga Composer on Salesforce · Twopir Consulting engagement
A legal team whose document generation was rebuilt on a governed template set with Salesforce reports and queries as the single data source, and output written back to the matter record with delivery logged.
What keeps that working is the unglamorous part: the template set stays governed, the solutions get re-tested when the platform moves, and the documentation stays current as the build changes.
Read the full case studyWhat the service actually promises
Agreed in writing, per engagement
Response targets by severity. Every Salesforce seasonal release regression-tested in a preview sandbox before it reaches your production org, with a written note of what changed. A governed template library reviewed on a set cadence. Documentation kept current. And a prioritised backlog that you control, not us.
Specific response times and capacity are commercial terms set per agreement against how critical your deployment is — we would rather agree them with you than publish a number that would not fit your situation.
Discuss a support arrangementSupport that reduces its own necessity
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 take deployments we did not build
Undocumented, half-finished, built by someone who has left. The takeover starts with an inventory, and you get that inventory whether or not you continue with us.
We test releases before they reach you
Regression testing in the preview sandbox is the single highest-value thing a Conga support arrangement does, and it is the thing in-house arrangements most often skip.
We fix causes, not symptoms
A recurring incident is a design problem wearing a support ticket. We would rather spend the time once than bill you for the same workaround every quarter.
We train your team out of needing us
Documentation stays current and admins get onboarded deliberately. If you end up cancelling because your own team can run it, that is a good outcome and we will have helped it happen.
We debug below the Conga layer
Most difficult Conga incidents are Salesforce data model, permission or query problems surfacing one level up. Being a Salesforce practice is what makes those solvable rather than escalatable.
Answers before the first call
Yes — that is a large share of what we support. It starts with an inventory of every solution, template, query, button and piece of automation, and an assessment of what is sound, what is fragile and what duplicates something the product now does natively. We do not require a rebuild as a condition of taking it on; keeping what works is usually cheaper and faster. You keep the inventory and the assessment whether or not you continue with us.
With the inventory, and it is a defined piece of work rather than open-ended discovery. Undocumented does not mean unreadable: solutions, templates, queries and automation can all be read from the org, and what they do can be established without the person who built them. The output is a written account of what exists and what state it is in. That document is what ends the key-person risk, and it is worth having even if you then decide to run the deployment yourself.
Because Conga solutions depend on the Salesforce org around them — objects, fields, permissions, automation and the behaviour of the platform itself. Salesforce ships seasonal releases, and a change to any of those can affect a solution that assumed the previous behaviour. Sandboxes receive the release before production does, which creates a window to test in. Using that window is the difference between finding breakage yourself and having a customer find it. It is also the item that in-house arrangements most often intend to do and never quite schedule.
They are agreed per engagement and written into the arrangement, set by severity and by how critical your deployment is. A document run that blocks month-end invoicing warrants a different commitment from a formatting issue on an internal report, and a single published number would either overpromise for one or overcharge for the other. We would rather establish what your actual severities look like and commit to those than quote a figure that has to be renegotiated later.
Often, yes, and we will say so if that is the honest answer. It works when you have a capable Salesforce admin who is permanent and genuinely has capacity — the failure mode is not capability but time, because release regression testing and template governance are the first things to get displaced by urgent work. Every implementation we deliver includes documentation and admin enablement specifically so in-house is a real option. If you want the middle ground, a support-only arrangement covers incidents and release testing while your team keeps day-to-day ownership.
Yes, and it is usually more effective that way because the products share the Salesforce layer underneath. An incident in CLM and one in Composer frequently trace to the same data model or permission cause, and the release regression set covers the whole estate rather than one product at a time. The inventory that starts the arrangement is scoped across everything you run.
Start Here
Find out what you are actually running
If nobody currently at your organization designed your Conga deployment, the inventory is the place to start. You will get a written account of every solution, template and query, what state it is in, and what would break it — whether or not you go any further with us.
Serving: US | Canada | UK | UAE | Australia | New Zealand
