Sometimes an existing platform handles most of the job, and the remaining problem sits between systems or at a handoff. A small extension can be useful there. I would define its boundaries carefully: the information it reads, the changes it may make, and the behavior it must preserve when a provider changes. The extension should have a job the team can explain and support.
Source
Integration is a design choice with continuing consequences
GDS’s current purchasing guidance includes combined approaches. That is useful permission to examine a narrow extension, but it does not establish that the integration will remain inexpensive.
I would give the extension a precise boundary and an exit condition. Its value should be demonstrable in the completed workflow, and its continued existence should remain open to review when the platform changes.
Proposal
Draw the responsibility boundary
Begin with a simple diagram. Identify the system that owns each important record, the event that starts the workflow, and the result the extension should produce. Avoid maintaining a second authoritative copy unless the design has a clear reason and a reconciliation method.
A hypothetical platform might manage documents and permissions well but leave a repetitive handoff into another application. An extension could read an approved event, locate the relevant record, and create a bounded update. That is a job the team can describe and test.
Describe this figure
A hypothetical combination of a bought platform and a small extension, drawn as the responsibility boundary. On the left, the source platform owns the record, and an approved event starts the workflow. Inside a dashed boundary sits the extension, which reads the approved event, locates the relevant record in the source platform, and creates a bounded update in the destination, another application. The destination result returns to the execution record, also inside the boundary, which the extension keeps alongside the source item and the attempted change, so one record connects source item, attempted change, destination result, and verification. The extension and the execution record are what the team builds and supports; the platforms on either side keep the work they are good at.
The GDS purchasing guidance recognizes combined approaches. The useful question is how much custom responsibility the combination introduces and whether it is justified by the missing capability.
Design for ordinary integration failures
An event can arrive twice. A request can time out after the destination accepts it. A provider can temporarily limit requests. A field can change or an account can lose permission.
Decide how the extension recognizes work it has already completed, how it checks uncertain outcomes, and when it stops retrying. Use product-supported mechanisms where available and verify their actual behavior. Expose failed or partial work to an owner who can reconcile it.
Keep an execution record that connects the source item, attempted change, destination result, and verification. Limit the sensitive data it contains. A supportable integration should not require an operator to search several broad logs to discover whether one record moved.
Keep access narrow
Give the extension the minimum practical access for its defined job. Separate configuration from credentials, use the approved credential-management approach, and document who can change either.
Test the workflow when access is denied or revoked. A silent failure can leave stale information in the destination while users assume the integration is still current. Show freshness or status where that matters to the business process.
Google’s simplicity guidance provides a useful design lens: each additional component needs to justify its operating complexity. Prefer a small, explicit boundary over a growing collection of exceptions that only the builder understands.
Plan for the platform to change
Assign an owner to review provider changes and test important upgrades. Record which interfaces and assumptions the extension depends on. Keep a small set of representative acceptance checks that can be rerun after a change.
Define how the extension can be paused while the underlying platforms continue operating. Decide how queued or partially processed work will be handled during that pause.
The vendor may eventually add the missing capability. Revisit the decision when it does. Retiring the extension can remove a useful amount of ongoing responsibility, provided the replacement meets the workflow and data requirements.
A successful combination leaves the platform doing the work it is good at and the extension performing a narrow, visible job. The value lies in the completed workflow and the team’s ability to maintain it.
Proposal
What I would test next
I would test repeated events, uncertain responses, and revoked access before broad use. If the extension needs an expanding set of exceptions to complete its basic job, revisit whether the selected platform and boundary are appropriate.