ServiceNow Integration Hub Requirements Workshop Questions

This page is a question set for an Integration Hub requirements workshop. It covers the system landscape, integration patterns such as one-way sync and event-driven triggers, data mapping, error handling, performance, security and governance, and how the answers feed the design.

Integration Architecture and System Landscape

Start by understanding your organization’s application landscape. What systems need to integrate with each other? Which are cloud versus on-premise? What does data flow between systems look like? Are there hub-and-spoke architectures (one system is central, others connect to it) or complex peer-to-peer integrations (every system talks to every other system)?

Questions to ask: How many systems does your organization need to integrate? Which are mission-critical? Which need real-time sync versus batch? Are there systems that are difficult to integrate (legacy systems, limited APIs)? Do you have integration middleware already or are you starting from scratch? Do you have integration governance (who owns integrations, how are they managed)? Answers inform Integration Hub configuration, data flow design, and infrastructure choices.

Integration Patterns and Use Cases

Different integrations need different patterns—some are one-way (sync from system A to B), some bidirectional (sync both ways), some are event-driven (when something happens in A, trigger action in B), some are scheduled batch (sync every night). Each pattern has different complexity, latency and failure modes.

Questions to ask: What are your primary integration patterns (one-way sync, bidirectional, event-driven, batch)? Which systems need real-time updates (customer data changes immediately affect orders), which can tolerate delay (reporting data can be daily)? Are there workflows that depend on multiple system updates (order creation updates inventory and billing)? How do you handle integration failures (retry, manual intervention, notify users)? Answers shape integration design and error handling strategies.

Data Mapping and Transformation

Systems rarely have identical data models. Customer data in system A might be structured differently than in system B. Integration Hub needs to map and transform data between systems. Mapping complexity depends on how similar the systems are—mapping between two ERP systems is usually straightforward; mapping between a legacy system and a cloud app requires more transformation.

Questions to ask: How similar is data structure across systems (are customer records structured the same way)? Do you need to transform data during integration (combine fields, split fields, apply business logic)? Are there data quality issues in source systems that need correction during mapping? Are there sensitive data fields that need masking or redaction during integration? How do you validate transformed data is correct? Answers inform data mapping complexity and testing requirements.

Error Handling and Recovery Strategies

Integrations fail—network outages, system unavailability, data validation failures. How are failures handled? Do failed records retry automatically, accumulate in a queue, or require manual intervention? How long should you retry before giving up? How do you know when integration fails?

Questions to ask: What’s acceptable latency for integration failure detection (should you know within minutes or is hourly acceptable)? How many retry attempts are reasonable? Should retries be immediate or with backoff (wait longer between retries)? When integration fails, who gets notified (operations team, system owner)? How do you manually process failed records (is there a UI for review and retry)? Answers inform error handling design and support requirements.

Performance and Scalability

How much data flows through integrations? If you have 1,000 customer records and 1 million transaction records, integration performance characteristics are very different. Do you need real-time integration or can batch work overnight?

Questions to ask: What volume of data needs to integrate (how many records per day, per hour)? What’s acceptable latency (real-time, within hours, daily)? Do integration volumes spike at certain times (month-end, year-end)? Have you experienced performance issues with previous integration approaches? Do you need to support multiple concurrent integrations or are they sequential? Answers inform infrastructure sizing and performance tuning strategies.

Security and Access Control

Integrations often move sensitive data—customer information, financial data, personal identifiable information. How is this data protected during integration? Are credentials encrypted? Is data encrypted in transit? Do systems authenticate each other?

Questions to ask: What sensitive data is integrated? Do systems use OAuth or API keys for authentication? Is data encrypted in transit (HTTPS, VPN)? Do integrations create audit logs (who changed what, when)? Are there compliance requirements (HIPAA, GDPR, PCI) that affect integration design? Do you need to mask sensitive data when logging? Answers inform security architecture and compliance design.

Governance and Maintenance

Integrations need ongoing management. When systems are updated, integrations may need to be updated. When data structures change, mappings need to be changed. Who owns each integration and is responsible for maintaining it?

Questions to ask: Who owns Integration Hub (platform team, business team)? How are new integrations requested and approved? When systems change, how quickly must integrations be updated? How do you handle integration deprecation (when a system is retired, how are its integrations removed)? Do you have integration documentation and runbooks for troubleshooting? Answers inform governance structure and operational processes needed to maintain integrations.

Running the requirements workshop so the answers change the design

A requirements workshop for integrations can produce a long list of answers that nobody uses. The questions were asked, the notes were filed, and the build started from the assumptions the architect already held. A workshop is only worth the time when each question is tied to a design decision it could change, and when the room agrees in advance what a worrying answer would mean. This section is written for the person running the session, usually a business analyst or integration lead, who needs to leave the room with decisions rather than transcripts.

Invite the people who own the data, not only the people who asked for the integration. The requester knows the outcome they want. The owner of the source record knows what it actually contains, how often it changes and who edits it without telling anyone. Without that second person, the workshop tends to design for the data the requester imagines.

Questions tied to the decisions they change

A running order for a three-session workshop

1. Start with the business event that triggers the integration and walk it end to end on a whiteboard, naming each system the event touches.
2. Take the data questions next, one field group at a time, with the source owner answering rather than the requester.
3. Close with failure and ownership questions, and finish by reading back every answer that the room marked as a risk.

Keep the sessions short enough that the source owner stays for all of them. A single long session tends to lose the people who hold the answers by the afternoon.

Answers that look fine and cause problems later

Some answers pass the room without comment and then cause rework. An answer that says the data is clean is one of them, because the team has not yet compared a sample. An answer that says the integration will run overnight is another, when the business process depends on the result in the morning and nobody checked the timing. Also treat a yes to every security question with suspicion. Ask which credential the connection will use and who can read it, because a broad answer often means the access model has not been thought through.

What to send out within a working day

Circulate a one-page decision record within a working day of the last session. List each decision made, the question it answered, the person who gave the answer and any open point that must close before design starts. The record is the document the build team will refer back to when the first disagreement arrives, so it should be short enough to read in a few minutes and specific enough to settle the argument.

Situations where a shorter exercise will do

A single small integration between two systems with one owner each rarely needs three sessions. A written questionnaire followed by one review may serve better. Use the workshop format when several owners hold parts of the answer, when the data crosses an approval boundary, or when earlier attempts at the same integration failed for reasons nobody agreed on.

Questions about running the session itself

How many people should attend?

The smallest group that includes each data owner and each person who can approve a design decision. Every additional attendee who is there only to listen slows the room down, and the answers come from the owners rather than from the audience.

What should we do when a source owner does not know an answer?

Record it as an open question, assign one owner, and write down when the answer is due. Do not let the design assume a value that nobody has confirmed, because the assumption will be the first thing tested in build.

Should the requester draft the question list?

The requester can propose questions, but the integration lead should trim the list to the questions that could change a decision. A long list read aloud in the room is less useful than a short one that the owners can answer without preparation.

For the credential questions, the security and access design page goes further, and the requirements workshop decisions article covers how to turn a session into a signed-off decision record. For the data side, the CMDB data quality rules article is useful when the source records are configuration items.