How to Gather Integration Requirements for SaaS Onboarding

Gather integration requirements before kickoff, in writing, with a named owner on each side. Teams that hit go-live dates treat integrations as a workstream with its own discovery call, requirements record, and acceptance criteria. Teams that miss dates treat integrations as a task called "connect to Salesforce" and discover the real requirements in week four.

This guide covers when to gather requirements, the nine questions to ask about every connection, who should own each piece, and how to keep the answers from drifting once the project is moving. The benchmarks come from 2025 and 2026 research by MuleSoft, Merge, Partner Fleet, and OnRamp.

What counts as an integration requirement in SaaS onboarding?

An integration requirement is any decision that determines how your product connects to a customer system: which systems connect, which direction data flows, how the connection authenticates, which fields map to which, how often data moves, and what happens when a sync fails. If the answer changes how you configure, build, or test the connection, it is a requirement.

Most teams under-scope this list. "We need the HubSpot integration" is a sentence from a sales call. The requirements behind it: which objects (contacts, companies, deals), which direction (two-way sync or a one-way pull), which plan tier the customer is on (API access and rate limits differ by plan), who can create the app token, and whether a sandbox portal exists for testing. One sentence in the deal becomes five decisions in delivery.

Integration requirements are also distinct from data migration. Migration moves historical data once; an integration keeps two live systems in sync indefinitely. The two share discovery questions but have different owners, timelines, and failure modes, so scope them separately.

Why do integrations delay go-live dates so often?

Because the dependency chain runs through people outside your project. The average organization now manages 957 applications, and only 27% of them are connected, according to MuleSoft's 2026 Connectivity Benchmark survey of 1,050 IT leaders. Every unconnected system your onboarding touches pulls a customer IT team, a security review, or a third-party admin into your critical path.

The build itself is rarely quick either. Per Merge's research, 71% of organizations take at least three weeks to bring a single integration to market, and the 2025 State of SaaS Integrations report found only 50% of companies complete integrations within three months. MuleSoft's data adds that IT teams spend 36% of their time designing, building, and testing custom integrations, and that 26% of IT projects shipped late in the past year.

The stakes cut both ways. Integrations come up in 60% of all sales deals, and 84% of businesses say integrations are very important or a key requirement for their customers. Once live, they hold customers: 98% of companies report that customers with integrations are less likely to churn, and Crossbeam's ecosystem research puts integration users at 58% lower churn. An integration delivered late delays exactly the thing that makes the customer stick.

When should you gather integration requirements?

Start during the sales cycle and finish before kickoff. Integrations shape the purchase itself: 90% of B2B buyers say a vendor's ability to integrate with their existing stack influences whether it makes the shortlist, and Gartner's software buying research ranks integrations among the top selection factors. By the time the contract is signed, someone on the buying side has already said what needs to connect. Capture it then.

In practice that means three checkpoints:

• During sales: the AE or solutions engineer records which systems came up, in what context, and which ones were commitments rather than possibilities. This belongs in the sales-to-onboarding handoff, in the customer's own words.
• Before kickoff: run a 30-to-45-minute integration discovery call with the customer's technical owner (agenda below), so the kickoff meeting presents a plan rather than opening an investigation.
• At kickoff: confirm the integration list, owners, and dates in front of the full stakeholder group, and say out loud which integrations are out of scope for phase one.

Asking for requirements after kickoff costs you twice: the build starts late, and the customer repeats things they already told sales, which erodes confidence in week one.

What questions should you ask about every integration?

Nine questions cover most of what delays projects. Ask them for each connection, record the answers, and treat every "we'll find out" as an open risk with an owner and a date.

Two of these deserve extra attention. Authentication is the most common hidden dependency: if the answer involves SSO, IP allowlisting, or a security review, ask on the call who approves it and how long approval took last time. Field mapping is the longest workstream: run it as working sessions with the customer admin rather than a form you send over. Unclear next steps and ownership rank among the top three killers of onboarding momentum in OnRamp's 2026 survey of 161 onboarding leaders.

Who owns integration requirements: your team or the customer's?

Split ownership at the system boundary, and put names on it. Your team owns your product's side: connector configuration, API documentation, the test plan, and your integration environment. The customer owns access and approvals inside their systems: credentials, sandbox provisioning, security sign-off, and a named admin for each connected system. Shared: field mapping decisions, acceptance criteria, and cutover timing.

The most common ownership failure is single-threading everything through your champion. Your buyer often cannot create a connected app, approve an allowlist entry, or provision a sandbox. Ask on the discovery call, "who administers this system day to day?", and get that person's name into the project plan. If a third party is involved (an agency runs their CRM, a consultant runs their ERP), get them on the discovery call too. Every extra hop adds about a week.

For enterprise customers, expect a formal security review before any credentials change hands, and budget two to six weeks for it. If you are onboarding your first enterprise customer, that review is usually the single longest integration dependency in the plan.

How do you keep integration requirements from drifting?

Write requirements down in one place, link each one to its source, and route changes through a visible decision. Integration requirements rarely arrive as one document. They surface one at a time: an auth constraint in a security review email, a mapping decision in a working session, a new "must have" system in a Slack thread on a Tuesday night. Whatever goes undocumented gets renegotiated later, and renegotiation is where timelines slip.

The failure pattern has a name: scope creep. A stakeholder mentions a second CRM in the customer Slack channel, nobody logs it, and three weeks later it has become "something you agreed to." The fix is the same discipline as preventing scope creep anywhere else: confirm the request in writing, log where it came from, and price it in go-live days.

Tooling matters here because the record is scattered by default. OnRamp's 2026 data shows 60% of companies still run onboarding across four to six tools, and 62% of leaders lack real-time visibility into where customers stand. Stipulate attacks this from the conversation side: it reads the customer Slack channel and call transcripts and keeps a live record of every requirement, decision, and risk, each linked to the message it came from. "Which auth method did we agree on, and when?" becomes a lookup with evidence instead of an argument.

How do you run an integration discovery call?

Book 45 minutes with your implementer or solutions engineer, the customer's technical owner, and the admin of each day-one system. Send the systems list ahead so nobody is guessing live. A working agenda:

1. Confirm the day-one list (5 minutes). Read back what sales captured. Ask what is missing and what can wait for phase two.
2. Walk the nine questions per system (25 minutes). Spend most of the time on authentication, field mapping, and sandbox access. Flag every "I need to check" as an action item with an owner.
3. Surface approvals and lead times (10 minutes). Security review? Change advisory board? Third-party admin? Get the process and its typical duration on record.
4. Agree acceptance criteria and dates (5 minutes). Define what "working" means for each integration and when testing starts.

Close with a written recap the same day: requirements confirmed, open questions with owners, and the dates entering the project plan. The recap is what protects the timeline; the call alone does not.

Which integration mistakes cause the most rework?

• Assuming the API exists. "We use that tool" says nothing about the plan they pay for. API access is gated to higher tiers in many products, and rate limits vary by plan. Verify tier during discovery, before the build is scheduled.
• Ignoring security review lead time. The review starts when the customer's security team picks it up, which is rarely the day you ask. Ask about the queue early and put the duration in the plan.
• Skipping the sandbox question. Testing a two-way sync against a production CRM risks real customer data. If no sandbox exists, decide the fallback up front: scoped test records, a read-only first pass, or an off-hours window.
• Deferring field mapping. "We'll map fields later" converts a two-week working session into a go-live blocker. Mapping needs the customer admin's calendar time, and calendars are the scarcest resource in any implementation.
• No failure-handling agreement. Half of organizations cite an integrated app or feature being discontinued or changed as an ongoing maintenance challenge, per Merge. Third-party APIs will change. Agree now who gets alerted and who fixes.
• Treating the champion as the admin. Enthusiasm does not come with credentials. Get the actual system admin named in week one, and a backup if they go on leave.

Next steps

If integrations keep stretching your onboarding timelines, do five things this week:

1. Add a systems-inventory question to your sales handoff so day-one integrations are captured before the contract is signed.
2. Put the nine-question checklist into your discovery template and schedule the discovery call before kickoff, every time.
3. Name an owner on both sides for every day-one integration, including the actual system admin, and add security review lead time to the plan.
4. Keep requirements, decisions, and open questions in one record with a link to where each one came from, and review it in your weekly status.
5. Write acceptance criteria per integration into your go-live checklist so "done" is testable.

Integrations win deals, keep customers, and sink timelines. The difference between the first two outcomes and the third is usually a discovery call that happened six weeks earlier.