Nothing comes back to the record
The file is generated and emailed, and Salesforce holds no evidence of what was sent, to whom, or when. That is exactly the question an audit asks, and the answer lives in somebody's sent items.
A document generated from incomplete data is worse than no document — it is wrong, on brand, and signed. Twopir Consulting connects Conga to the systems that feed it and the systems that receive what it produces: Salesforce, ERP and finance, e-signature, and your content stores. Both directions designed, not just the outbound one.
Trusted by 500+ organizations — connecting Conga to the CRM, finance, signature and storage platforms their business already runs on.












Integration Coverage
Most Conga integrations are built outbound-only, because that is the half that makes the demo work. The failures all live in the half nobody designed.
The file is generated and emailed, and Salesforce holds no evidence of what was sent, to whom, or when. That is exactly the question an audit asks, and the answer lives in somebody's sent items.
Pricing lives in the ERP, quoting happens in the CRM, and the two are synchronised by someone remembering to. Finance finds out at billing, and the customer finds out at the same time.
Generated documents accumulate in Salesforce rather than in the content store where your retention and access policies actually live. Storage limits arrive first; the compliance question arrives later.
The agreement is signed in the e-signature platform and the Salesforce record still says "sent". Renewals get calculated from the wrong date and nobody notices for a year.
The storage platform is unavailable for twenty minutes. Does the merge fail loudly, retry, or silently drop the file? If the answer was never designed, you find out during a busy quarter-end.
A field gets renamed, a picklist value is added, a profile changes. The mapping still points at the old shape, and the merge quietly produces a blank where a number should be.
Conga integration is the work of connecting Conga to the systems either side of it: the platforms that supply the data it merges, and the platforms that receive what it produces. These are the four that decide whether a deployment feels automated or merely automated-looking.
Purpose — so every document, agreement and quote is generated from the live record rather than from an export somebody made last Tuesday. Outbound — record data, Salesforce report results and query output reach Conga at merge time. Return — the finished file, its delivery status and an activity record are written back onto the source record. Sales sees what was sent; legal and finance see the evidence.
Purpose — so the price on the quote and the price on the invoice are the same number. Conga connects to ERP and finance platforms including SAP and NetSuite. Outbound — product, price-list and entitlement data flow from the ERP into the quoting and document layer. Return — accepted quotes, executed agreements and their commercial terms flow back for billing, so finance stops reconciling two versions of one deal.
Purpose — so signature is a step in the process rather than an errand in another tool. Conga Sign is native; Conga Composer also integrates with DocuSign for Salesforce where an organization has standardised on it. Outbound — the generated document and its recipient routing go to the signature service. Return — completion events, the executed copy and the audit trail come back to the Salesforce record, which is what closes the loop for legal and revenue operations.
Purpose — so generated files live where your retention and access policies already apply, instead of accumulating as untracked Salesforce attachments. Outbound — finished documents are written to SharePoint, Box or Google Drive under a designed folder and naming convention. Return — the resulting link is written back to the Salesforce record, so users reach the file from the record and IT keeps one storage policy rather than two.
The rule we design to
Every flow gets a return path. If data leaves Salesforce and nothing comes back, you have built an export, not an integration — and the record that started the process is now the least reliable place to find out what happened to it.
That is also the cheapest thing to get right at design time and the most expensive to retrofit, because by then the missing history is genuinely gone.
Some of these are packaged connectors and some are genuine integration engineering. Which one you are facing changes the estimate by an order of magnitude, so we establish it during discovery rather than at build time.
Which systems, which direction, which fields, and what the business actually does with the result. Most integration overruns trace back to a field nobody asked about.
The unglamorous half that decides whether the output is right. Documented mappings, with the transformations and the defaults written down rather than living in someone's head.
Where a packaged connector exists, we configure it properly rather than building around it — including the settings most deployments leave at their defaults.
Where no connector exists, or the requirement is past what one can do. Built to Salesforce standards so the next engineer can read it.
Designed as deliberately as the outbound flow: what gets written back, where it lands, and how someone looking at the record a year later reconstructs what happened.
Existing documents and agreements brought into the new arrangement, so the integrated process does not start with an empty history.
These two words get used interchangeably in sales conversations and they differ by an order of magnitude in cost. Knowing which one you are buying is the whole estimate.
| Packaged connector | Custom integration | |
|---|---|---|
| What it is | A supported connection the vendor already ships, configured to your data and process. | A connection engineered against the platforms' APIs because no supported one covers the requirement. |
| Typical cases | Conga to Salesforce; Conga Composer to DocuSign for Salesforce; standard content-store output. | ERP pricing sync; portal-embedded generation; a system with no published connector; unusual routing logic. |
| Work involved | Configuration, field mapping, permissions, testing. | All of that, plus authentication, orchestration, error handling, retry design and monitoring. |
| Who maintains it | The vendor maintains the connector; you maintain the configuration. | You do — which means it needs documentation and an owner from day one. |
| The risk | Assuming it covers a case it does not, and discovering that during UAT. | Under-scoping the non-happy paths. The build is rarely the hard part; the failure modes are. |
Conga Composer on Salesforce · Twopir Consulting engagement
A legal team generating client-facing documents by hand, with no reliable record of which version went out. The integration work made Salesforce reports and queries the single data source, and wrote generated output back to the matter record with its delivery logged.
The change people noticed was not speed alone — it was that the document on the record and the document the client received became the same object, which is what made the process auditable.
Read the full case studyDelivered with every integration engagement
A written integration map — every system, every flow, every direction. Field mappings with their transformations and defaults. A stated behaviour for each failure mode. And a test that proves the return path, not only the outbound one.
Undocumented integrations are how organizations end up unable to change a field name. The map is a deliverable precisely so that the next change is a decision rather than an investigation.
Map your integrationsWe 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.
Connecting business systems is a core part of what we do across Salesforce and beyond, so the ERP link and the portal embedding are the same team rather than a subcontractor introduction.
What comes back to the record is where the business value and the audit trail live. Starting there tends to expose requirements that an outbound-only design never surfaces.
If a supported connector covers the requirement, that is what we configure. Building a custom integration where a packaged one would do is expensive for you and a maintenance liability for whoever inherits it.
What happens when the storage platform is unavailable, when a signature expires, when a record is deleted mid-flow. Each one gets a stated behaviour before it happens in production.
Every flow, every field, every transformation, written down. It is what lets your team change a field name in a year without commissioning an investigation first.
Salesforce first and most deeply, since several Conga products run natively inside it. Beyond that, Conga connects to ERP and finance platforms including SAP and NetSuite, to e-signature through Conga Sign natively and DocuSign for Salesforce through a connector, and to content stores such as SharePoint, Box and Google Drive. Conga also publishes APIs for embedding its capability into portals and custom applications. The useful question is not what it can connect to but which connections your process actually needs — that is a discovery conversation, not a feature list.
It depends on whether a supported connector covers your actual requirement rather than the general shape of it. A connector that moves documents to a content store may not handle your folder taxonomy or your naming convention; a native CRM connection may not carry the one custom object your process depends on. We establish this per flow during discovery and tell you which side of the line each one falls on, because the two differ by an order of magnitude in cost and getting the assumption wrong is what makes integration estimates unreliable.
Yes, and for most organizations that is the right design. Output can be written to SharePoint, Box or Google Drive under a folder structure and naming convention you define, with the resulting link written back to the Salesforce record so users still reach the file from the record. The benefit is not only storage consumption — it is that your existing retention, access and legal-hold policies already apply there, rather than needing to be recreated around Salesforce attachments.
Whatever you decided it should. That sounds glib but it is the actual answer: the failure behaviour is a design decision, and the projects that go wrong are the ones where nobody made it. Options are to fail loudly and stop the process, to queue and retry, or to proceed and reconcile afterwards — and the right choice differs per flow. We specify a behaviour for each one and test it, rather than finding out during a quarter-end. The engineering patterns behind retry and reconciliation are covered on Conga API and integration architecture.
Yes. Migration usually involves moving files into the target store under the new folder and naming convention, associating each one with the right Salesforce record, and normalising whatever metadata exists. The part that takes longest is rarely the transfer — it is the reconciliation: deciding what to do with documents that cannot be matched to a record, duplicates, and files whose naming tells you nothing. Where a contract estate needs structured data extracted rather than just filing, that is Conga AI and contract intelligence.
Usually, and the first step is an audit rather than a rebuild. Recurring breakage normally traces to one of three causes: field mappings that were never updated after one side changed shape, no defined behaviour for failures so errors surface as silent gaps, or a custom build with no documentation and no owner. We establish which it is, fix the cause rather than the symptom, and leave you the integration map. Ongoing regression testing against Salesforce seasonal releases is covered by support and managed services.
Bring us the flow that costs your team the most reconciliation. We will tell you whether a packaged connector covers it or it needs engineering, what the return path should carry, and what a realistic scope looks like — before you commit to anything.
Serving: US | Canada | UK | UAE | Australia | New Zealand