ServiceNow REST and SOAP Integrations Requirements Workshop Questions

This page gives the questions to settle in a requirements workshop before ServiceNow REST or SOAP integrations are designed. Work through the direction of each integration, the timing and trigger of syncs, which system is the source of truth, the authentication method and any rate limits. The questions also cover data mapping, error handling, security, performance and monitoring.

Mapping Integration Patterns and Use Cases

Before designing REST or SOAP integrations, understand what you need to integrate and why. Are you pulling data from external systems into ServiceNow (inbound sync)? Pushing data from ServiceNow to external systems (outbound sync)? Or both (bi-directional sync)? For each integration, understand the use case: for example, syncing employee data from HR system to ServiceNow employee records (inbound), or updating case status from ServiceNow to customer portal (outbound). Understanding your integration patterns drives decisions about API design, data flow, and synchronization frequency.

Synchronization Strategy Workshop Questions

When does data need to sync? Real-time (within minutes), batch (hourly or daily), or event-driven (when specific business events occur)? Real-time is most accurate but more complex; batch is simpler but may allow stale data. What triggers a sync? Schedule (e.g., every hour), business event (e.g., when a case closes), or API call from external system? Which system is the source of truth? If employee data changes in both HR and ServiceNow, which one wins? How do you handle conflicts when data differs between systems? Do you synchronize the latest change, or do you alert someone to resolve the conflict? What level of data validation occurs before syncing? Do you validate external data before importing, or do you validate after importing? How do you handle sync failures? If ServiceNow API call fails, do you retry immediately, queue for later retry, or alert someone?

API Design and Authentication Questions

Does the external system have a documented API, or do you need to reverse-engineer or negotiate a new integration? Documented APIs are faster; undocumented or proprietary protocols require more effort. What authentication mechanism does the API use? API key, OAuth 2.0, basic auth, or custom? Does the API rate-limit requests? If so, how many requests per minute or per day? This affects how you design batch operations; if you can only make 100 requests per hour and you need to sync 10,000 records, you need to batch efficiently. Does the API support filtering? If you need only recent changes, can you request only changed records since last sync, or do you have to fetch all records every time? What data format does the API use? JSON, XML, CSV, or custom? JSON and XML are standard; custom formats require custom parsing.

Data Mapping and Transformation

Do external system field names match ServiceNow field names, or do you need mapping? If HR system calls a field employee_id and ServiceNow calls it employee_number, you need to map them. Do you need to transform data? For example, HR system has yes/no, ServiceNow uses true/false; you need conversion logic. What do you do with fields that do not map? Some external system fields may not have a ServiceNow equivalent. Do you store them in a custom field, archive them, or discard them? How do you handle missing required data? If an external system record lacks a field required in ServiceNow, do you skip the record, use a default value, or alert someone?

Error Handling and Resilience Questions

What happens when an API call fails? Do you retry immediately, wait and retry, queue for later, or alert an operator? How many retries are acceptable? Retry 3 times with exponential backoff (wait longer each time) is common. What do you do if retries exhaust? Move to a dead-letter queue for manual review? Alert on-call support? How do you monitor integration health? Track success rate (percentage of syncs that complete without error), latency (time from source change to sync completion), and failure reasons (which errors occur most often). What is your acceptable error rate? Most organizations accept no errors for critical data, only minimal errors for non-critical data.

Security and Compliance Questions

What sensitive data is being integrated? PII (personally identifiable information), financial data, health data? Does data need to be encrypted in transit? HTTPS/TLS encryption is standard for APIs. How is access controlled? Are API calls limited to specific ServiceNow users or service accounts? Does the integration need audit logging? Can you prove who synced what data when? Are there compliance requirements? GDPR requires that you can delete PII when requested; does your integration support this? What is your data retention policy? How long do you keep synced data?

Performance and Scalability Questions

How much data are you synchronizing? Thousands of records or millions? How often does data sync? If you sync millions of records every hour, you need efficient batching and indexing. What are acceptable performance bounds? Must a full sync complete in one hour, or can it take longer? Does the integration impact ServiceNow performance? If integration jobs consume a lot of CPU or network, can you schedule them during low-use hours? Do you need to paginate? If an external API returns 10,000 results at a time and you can only process 1,000, you need pagination logic.

Monitoring and Operational Questions

Who is responsible for monitoring integrations? Platform team, application owner, or integration specialist? What dashboards or reports do you need? Daily sync status, success/failure rates, data quality checks. When should you alert operations? If a sync fails three times in a row, if latency exceeds threshold, or if data quality drops below expected levels. How do you validate data after syncing? Spot-check samples, automated data quality rules, or comparison against source system.

Run the workshop around decisions, not around a list

A requirements workshop for an integration produces its value in the answers that change the design. Questions that merely collect facts can be sent in a document beforehand. The useful ones are those where two different answers would lead to two different builds. The workshop should therefore finish with a decision log: each open question, the answer given, the person who gave it, and the design consequence. Notes without a decision log tend to reopen the same debate in the first build review.

Questions that change the design most

Answers that should pause the project

Some answers do not change the design but should stop the build until they are resolved. A consumer who cannot name what data they need, an owner who has not been identified for the remote system, and a sponsor who expects the integration to remove a manual step without saying which people will still perform it are common examples. Recording these as blockers rather than assumptions protects the team. An assumption made in a workshop tends to become a requirement that nobody remembers agreeing to.

An ordered sequence for the session

1. Confirm the purpose of each connection in one sentence, and drop any connection whose purpose needs a paragraph to explain.
2. Walk through the source-of-truth table field by field, not as a general discussion.
3. Ask the consuming team to describe a bad day for their data, then ask what they would need to see to know it had happened.
4. Agree the test approach and state what it will not prove.
5. Read back the decision log and get each attendee to confirm the lines that affect their area.

Who should attend

The people who run the source system and the people who use the data should both be in the room, because each knows a set of answers the other lacks. A security reviewer is needed whenever personal or financial fields move. Leave out the people who only receive the summary; they can review the decision log afterwards and raise objections there, where they can be recorded.

Questions about running the workshop

How much detail do we need before the workshop?

Enough to name each connection, its direction and the systems involved. Field-level detail is better gathered in the room, because the people who own those fields will often correct the first draft.

What if the remote system has no documentation?

Record that as a finding with a consequence: a discovery step, a sample extract or a supplier meeting becomes a prerequisite before the design can be fixed. Undocumented interfaces are a schedule risk, and the workshop should say so.

Should the workshop agree the security design?

It should agree the data classification and the identities that need access. The detailed access design is a separate piece of work, reviewed by the security owner against those answers.

Request a facilitator’s review of the question set

A second look often catches the question the team missed. The security and access design guide picks up the identity questions from this session, and the owner assignments that follow are covered in the roles guide. Framing why each connection exists is a strategy question, and the strategy piece on business events helps with that. The piece on REST integration design covers the technical choices that follow from the answers.