Move information once, with a way to see what happened.

A private-group activity request arrives on a website, but staff review availability in another application. Connecting those tools can save copying if the receiving record remains an enquiry that needs a decision. It must not become a confirmed booking simply because an integration accepted a message.

Map one request completely

For this hypothetical New Zealand operator, choose a sample request with two possible dates and an approximate party size. Give it a stable reference. Identify which receiving fields can represent a date preference and which require a confirmed date; if the second application cannot preserve the distinction, staff need a review task or another suitable arrangement.

The customer contact, activity and original wording should remain available to the person assessing the request. A rough group size should not be converted into an exact commitment without a business decision. We inspect the selected applications' supported interfaces and account permissions before promising a connection.

Resolve an uncertain handoff

Suppose the receiving service creates the review task but the connection loses its response. Before retrying, it needs a way to recognise that request reference or ask staff to reconcile it. Two review tasks can lead to two conflicting offers even where no money changes hands.

Include a rejected field, a changed date and a request that staff have already answered. Agree which system owns the current decision and what should happen when the website receives an older update.

Leave something staff can operate

The handover explains the field mapping, account owner and visible queue for exceptions. Provider changes may need maintenance. Acceptance compares the actual records on both sides; a successful send alone is insufficient.

Bring the application names and a redacted example of the request staff currently copy. Assess a system connection →