The happy path is the easy ten percent.

Yes. Conga publishes APIs specifically so its capability can be embedded into websites, portals and custom applications, which is the route when a customer-facing user needs to produce a document without a Salesforce licence. The API call is the straightforward part; the design work is the security model. Portal, guest and community contexts have different sharing and permission behaviour from internal users, so generation that works for an admin can either fail or expose more data than intended for an external user. We model that first and build the interface second.

Decide it on worst-case latency and on what the user is doing while they wait, not on which is simpler to build. Synchronous is right when a person is waiting and the work is genuinely fast at production data volumes — and that qualifier matters, because generation that returns instantly against a test record with four line items can take far longer against a real one with four hundred. Where the work is variable, large, or batched, asynchronous with a callback and a visible status on the record is the durable choice. The failure mode of getting this wrong is a timeout that has already partly committed.

With an idempotency key supplied by the caller and scoped to the logical operation rather than to the HTTP request, so a repeat of the same logical action is recognised as the same action. Without one, a client-side timeout on a request that actually succeeded produces duplicate work on retry, and you cannot tell afterwards which result is canonical. Pair it with explicit classification — retry transient failures with backoff and a ceiling, record permanent ones and surface them — and with a dead-letter path for exhausted retries. This is the hardest property to add later, because retrofitting it means reasoning about every operation already performed.

Only if you need orchestration that genuinely spans several systems, or transformation and routing complex enough to deserve its own home. For a point-to-point integration between Conga and Salesforce, an iPaaS often adds a platform, a licence and a second place for business logic to hide without answering the underlying design question. The question worth settling first is where the orchestration lives — Salesforce, a platform, or your own service — because splitting logic across two of them is what makes a process nobody can describe in one place. Where a platform is justified, we deliver on it.

By modelling the whole org's consumption rather than this integration's, since the allocation is shared and the thing that breaks is often not the thing that exhausted it. Practically: prefer event-driven patterns over polling, batch where the API supports it instead of issuing one request per record, cache reference data that changes rarely, and monitor headroom continuously rather than discovering the ceiling during a peak. We do not publish specific allowances here because they vary by edition and change — we read your actual current limits and consumption during design.

Yes, and it is a common starting point — particularly where an integration works but nobody is confident about what happens when it does not. The review covers the six decisions on this page: interaction shape, credential handling, idempotency, failure classification, observability and where orchestration lives. The output is a written assessment with prioritised findings, and in our experience the two most frequent gaps are missing idempotency and no correlation id spanning the hops. You keep the assessment whether or not we do the remediation.