Show How an Integration Works Without Calling Every Connection Native

Two logos with a line between them make one claim: these products have something to do with each other. They don't say what crosses the line, what starts the crossing, or who is responsible when nothing arrives at the far end.

So the buyer asks whether the two systems "sync," and the presenter says the integration is native. Now one word is carrying an entire explanation, and it can't. "Native" might mean the vendor built it, or that nobody wrote code for this customer, or that no configuration is needed, or that the two products happen to use compatible objects. Four different claims, one adjective — and none of them describes what the customer will see on Tuesday morning.

The replacement is smaller than it sounds. Describe one exchange, all the way through. Not a catalog of everything the two products could theoretically do: one path, from the moment something happens in the first system to the moment the second system acts on it, including the place where it stops.

The shape is short enough to memorize: when something happens, what moves, in which direction, with what result, and where the handoff ends. A presentation that can answer those five in a few sentences never needs the word native, and it survives the follow-up question that a logo row invites.

Describe one exchange, not the catalog

Pick the exchange your buyer's job depends on. For a support tool, it's usually the one that turns a submitted request into a task. For billing, it might be the one that turns a closed ticket into an invoice line. Pick one and go deep. A buyer who understands one path will extend trust to the rest of your description; a buyer who has watched you skate across eight logos will ask about the ninth.

Use the customer's nouns, not the mechanism's. "A submitted request becomes a task for the person named on it" is a sentence someone can picture. "Bi-directional synchronization across the service management suite" is a category, not an event. Nobody in the room has seen it happen.

Trigger, payload, direction, result — and one more

Trigger. A person submits a request. A record changes status. A timer fires. Someone drags a file onto a page. Name the one that applies. This is where the customer's mental model either matches yours or quietly diverges for the rest of the evaluation.

Payload. Which object moves, and which fields travel with it. Request ID, title, owner, submission time — and say what's missing, because the gaps become dependencies later. A payload carrying only an identifier means the receiving side has to fetch the rest, which is a second exchange with its own triggers and its own failure modes. "It sends the request" is not a payload description.

Direction. One way or two. If two, count them as separate exchanges with separate triggers and separate ways to break. A task appearing on the board is one exchange. A completion status appearing back in the request tool is another. Presenters collapse them because "two-way sync" sounds stronger, then get caught when only the return leg fails.

Result. What the receiving system does with what arrived: creates a task, appends a note, posts to a channel. This is the business outcome, and it deserves its own sentence, distinct from the transfer that preceded it.

Boundary and owner. Where the path stops, and who acts when it stops there.

Put together, a presenter's sentence can sound like this: When someone submits a request in the first system, an event carrying the request ID, title and owner is delivered to the second, and the second creates a task assigned to that owner. The owner has to exist there first; if no matching user is found, the exchange stops at that step and the next action belongs to the integration owner, not to the requester. We haven't measured the typical delay. Trigger, payload, direction, result, boundary and owner — plus a dependency and an honest gap. Read it next to a logo row and the row stops looking like a substitute.

Push, poll, and a person with a file

Three mechanisms produce the same sentence — "a request becomes a task" — and they are not interchangeable from the buyer's side of the table.

GitHub's documentation on webhooks, which I looked at in September 2026, distinguishes event subscriptions that deliver event data to an endpoint you configure from asking the API for information on a periodic basis, and it notes that the receiving side has its own work to do with what arrives. That's one vendor documenting one platform's mechanics, and it's a clean way to explain the difference between a push and a poll. It is not evidence about any other product, and it doesn't establish that your integration exists — a platform documenting a mechanism is not the same as a company having configured one.

So: delivery because something happened, delivery because a clock said so, or delivery because a person exported a file and uploaded it. All three are legitimate. Each produces a different delay, a different failure signature, and a different person holding the next action.

Two phrases to retire while you're at it. "Real-time" almost never survives a measurement. "Automatic" usually means no human presses a button per record, which can be true of a job that runs at 2 a.m. If you mean "the task shows up without anyone on our side doing anything," say that. If you don't know how long it usually takes, don't supply a number — say what's known and say what hasn't been measured.

A delivered event is not a finished task

Delivery succeeds when the receiving endpoint acknowledges that something arrived. Whether a task exists depends on what the receiver does next: resolve a user, match a record, accept a field, apply a rule.

Those are different events, and they can disagree. "The event was delivered" is the most misleading sentence in an unqualified integration pitch, precisely because it's true, checkable, and tells the customer nothing about whether their request turned into work. Keep the two sentences apart in your own head, and they'll stay apart on the slide.

An invented pair: RequestDesk and Taskboard

An example makes this faster to see. It's invented — two fictional products, RequestDesk and Taskboard — and I didn't build the connection, move a record, or watch anything fail. Treat it as a shape, not a claim about any real product. The failure below is a design stipulation chosen to make the mechanics visible.

The business event: a request is submitted in RequestDesk. The result the buyer cares about is a task in Taskboard, assigned to the person named on the request.

The exchange as a presenter would say it: when a request is submitted, an event carrying the request ID, title, owner address and submission time is delivered to the Taskboard workspace, and Taskboard creates a task assigned to the matching user. The request ID is stored on the task so the support team can find the original.

That's one direction. Nothing is written back to RequestDesk, so if the customer needs completion status to reappear in the request tool, that's a second exchange and it needs its own description.

The same business outcome could honestly be produced three ways. Nothing in this table is a measurement of a real system; it's one invented outcome described under three mechanisms, which is what makes them worth comparing.

The difference between those rows is far larger for the buyer than the difference between two logo tiles.

The dependency. The connection needs a mapping from the request's owner address to a Taskboard user, plus credentials the endpoint uses to accept deliveries and someone with permission to maintain the mapping. On a slide, those are named as dependencies — endpoint, secret, mapping table, the team that maintains it. The values themselves never go on a slide.

The failure. Now the part that makes the diagram useful. Suppose a request arrives with an owner address that doesn't match any Taskboard user. In this design, the endpoint accepts the delivery and then fails at the mapping step: it writes a rejected entry to the delivery log and creates no task. RequestDesk records the event as delivered, because from where it stands, delivery succeeded. The requester sees a submitted request with nothing behind it, and nobody is notified, because this design has no alert on rejected deliveries.

The opposite arrangement is just as easy to build: the endpoint refuses the delivery, and the sender marks it failed. The two arrangements put the visible symptom in different places, and a logo row shows neither. Which one you're describing is a fact about your implementation, not a preference — so it has to be checked rather than chosen for how it sounds.

Who acts next. In the example, the next action belongs to the Taskboard integration owner: create the missing user, or add a rule that routes unresolvable owners to a triage queue. The requester can't do either, and usually doesn't know a task was supposed to exist. Say that out loud in the presentation. Naming the person who owns the stuck request is more reassuring than any claim about reliability, and it happens to be checkable.

Label the connection at the level you can support

With one exchange described, the label takes care of itself:

Configured. The standard mechanism, switched on through settings. No code written for this customer. Custom. Built or adapted for this pairing. Say what was adapted and who maintains it. Manual. A person moves the data. That's the trigger; it belongs on the diagram. Planned. Agreed, not built. It's fine to show it, in a different visual state from anything live. Verified. Someone watched the exchange complete, on a date, for a named scope. "We watched this run end to end in March for three accounts" is a verification. "It works" is not.

Manual steps sit inside otherwise automatic paths all the time — someone has to create the user, approve the mapping, or upload the first file before anything flows. That's an accurate description, not a weakness, and buyers generally prefer hearing it in the room to discovering it in onboarding.

As for "native": if the company wants the word, define it on the slide. Native meaning built and supported by the vendor is a different statement from native meaning no code was written, and both are different from native meaning the two products share an object model. One definition, stated once, then the concrete sentence. In most decks the concrete sentence is more persuasive anyway: requests submitted in RequestDesk appear as tasks in Taskboard, assigned to the person named on the request, with the original request linked. The owner has to exist in Taskboard first. We haven't measured the typical delay.

What the diagram has to show

Draw the path, not the partnership. Logos go small in the corners; the exchange is the content. Mark every transition, and stop the drawing where the evidence stops — a seamless loop the presenter can't describe is worse than an open arrow with a question beside it.

What the invented example looks like drawn out:

LOGOS (small):  [RequestDesk]                          [Taskboard]

TRIGGER         request submitted in RequestDesk
PAYLOAD         request_id · title · owner_address · submitted_at
DIRECTION       one way  RequestDesk ─────────────▶ Taskboard
                (no status written back)

                             │
                             ▼
                 endpoint receives the event
                             │
                             ▼
                 map owner_address → Taskboard user
                             │
          ┌──────────────────┴──────────────────┐
          ▼                                     ▼
   resolved                               unresolved
   task created,                          rejected entry in
   assigned to that user                  delivery log
   request_id stored on task              no task created
                                          no notification sent
                                          next action: integration
                                          owner (create user, or
                                          route to triage)

CONSEQUENCE     a task exists for the owner — or nothing does
BOUNDARY        the path ends here. Reliability, volume, and
                long-run behavior are not established by this diagram.
LABEL           configured event delivery; owner mapping maintained
                by [team]; delivery delay not yet measured

Everything above the last arrow is the part the presenter can defend. Everything below it belongs to whoever owns the next action, and the diagram says their name.

The question to leave with

A buyer who has seen this much can ask one question that reveals the whole mechanism in any product, including yours:

"Walk me through one request that never arrives, tell me exactly where that state is visible, and tell me who owns the next action."

Frequently asked questions

What should replace the word 'native' when describing an integration?

Describe one exchange all the way through: when something happens, what moves, in which direction, what result follows, and where the handoff ends, including who owns the next action. That concrete sentence can also carry dependencies and an honest unmeasured gap, such as a delivery delay that has not been measured.

Why can 'a delivered event' be true without the customer's task existing?

Delivery succeeds when the receiving endpoint acknowledges that something arrived. A task exists only if the receiver then resolves a user, matches a record, accepts a field, or applies a rule. Those are different events and can disagree, so a delivered event says nothing by itself about whether a request became work.

How do push, poll, and manual upload differ for a buyer?

They can produce the same sentence—'a request becomes a task'—but they differ in trigger, delay, failure signature, and who holds the next action. Event delivery happens because something happened, scheduled import because a timer fired, manual upload because a person exported and uploaded a file. 'Real-time' and 'automatic' should not be used unless their precise meaning is stated.

What labels can replace 'native' if a company still wants categories?

Use configured (standard mechanism switched on through settings), custom (built or adapted for this pairing, with what was adapted and who maintains it), manual (a person moves the data), planned (agreed but not built, shown in a different visual state), and verified (someone watched the exchange complete, on a date, for a named scope). If 'native' is used, define it on the slide.

In the invented RequestDesk–Taskboard example, what happens when an owner address does not match, and who acts next?

The endpoint accepts the delivery and then fails at the mapping step: it writes a rejected entry to the delivery log and creates no task. RequestDesk records the event as delivered, the requester sees nothing behind the submitted request, and no notification is sent. The next action belongs to the Taskboard integration owner—create the missing user or route unresolvable owners to triage. The example is invented and not a measurement of a real system.

Further reading

• Choose a Product Demo Scenario That Shows a Real Workflow — Read this first when deciding which exchange to describe, so the integration demo starts from one task the buyer already recognizes.
• Prepare a Demo Fallback That Still Answers the Question — Keep this for when the live exchange cannot be shown, to preserve the part of the evaluation still deliverable and state what is no longer live.
• Demonstrate a Service With the Human Work Still Visible — Read this when an exchange includes manual steps or backstage work, to keep the human handoffs and the waiting visible beside the automated path.