Why Integrate — Seven Benefits
1
Improved efficiency — automate internal & external resources, removing boundaries between people, data, systems, and processes2
Better decision making — solve problems faster by integrating legacy systems, ERP, on-prem apps and data sources with no boundaries3
Standardization — link systems and wrap processes with workflow logic and automation tooling4
Increased productivity — boost speed through re-use and out-of-the-box integrations5
More accurate data — integrate with master data at its source to avoid redundancy6
Automation — extend workflows to core enterprise systems, no-code or enterprise-grade7
Cost reduction — reuse the strategic workflow platform already in place rather than building anewTypes of Integration
Cloud-Based
Bi-directional, data-level integration that can trigger a process or specific action. One system publishes the service, the other consumes it. Import sets load external data over HTTPS/SFTP as XML or CSV.
Model →
Point-to-Point
Direct read/write access to another system via a protocol or API — encrypted (HTTPS, LDAPS), secured (SSL + digital certificates), and authenticated (user/password, public/private keys).
Examples →
MID Server-Based
Also a point-to-point pattern, used when firewalls prevent direct access to the enterprise system. The MID server sits behind the firewall and reads/writes on ServiceNow's behalf.
Use When →
🎯 Ultimate Objective: Every integration decision should ladder up to enhancing the efficiency, quality, and cohesion of organisational operations — not integration for its own sake.
Four Integration Options
ServiceNow In-Product
- Pre-built integrations within an application
- HRSD ↔ SuccessFactors
- GRC ↔ Thomson Reuters Regulatory Intelligence
- CSM Social · Multifactor Authentication
ServiceNow Store
- Built by ServiceNow or a partner
- DocuSign · Zoom · Jira · SolarWinds
IntegrationHub Spokes
- Pre-built, primarily outbound
- MS Teams · Slack · Azure AD
- Lucidchart · Exchange Online · Google Calendar
Build Your Own
- Flow Designer with IntegrationHub
- Native REST, SOAP, import/export abilities
Integration Protocols
REST & SOAP
- Web-service technologies calling data/functions over HTTP/S
- e.g. ServiceNow as provider or consumer
LDAP/S
- Queries data on directory servers
- e.g. user sync with Active Directory
SFTP
- Secure file transfer to/from a server
- e.g. import CSV from an external SFTP server
XML
- Custom-tag markup defining data & structure
- e.g. node-based data parsed via XPath
File
- Delimited text/CSV data storage
- e.g. comma-separated values
JDBC
- Java access to relational databases
- e.g. SQL queries via MID server
IntegrationHub
🔌 Spokes Reusable
Run-ready connectors with predefined, documented functions and tailored input/output parameters. Encourages configuration over customisation. Custom spokes and actions can be built with native protocols (REST, SSH, JDBC) when a baseline spoke doesn't exist.
🔗 Decoupled Connections Config-Driven
Connection information (URL/JDBC server, credentials) is defined separately from the integration logic via connection and credential aliases — so the connection can change (e.g. Dev → Test → Prod) without touching the integration action.
💡 IntegrationHub Benefit: Drag-and-drop spokes cut scripting and technical debt, simplifying both deployments and upgrades — while still allowing REST/SOAP or script steps for anything a baseline spoke doesn't cover.
ServiceNow as Provider vs Consumer
📤 Provider Publishes API
Creates a REST/SOAP endpoint to provide read, create/update, or delete data, or expose a function. e.g. ordering a catalog item, creating an incident via API Explorer.
📥 Consumer Uses API
Uses a REST/SOAP endpoint to request, create/update, or remove data, or use a service. e.g. language translation, currency calculation, sports/weather data, statistical metrics.
Parsing the Response Payload
JSON
- Most common REST return format
- Built-in globally-scoped Script Include parser
- Native JS object also provides a parse method
XML
- Returned from SOAP calls (can embed JSON)
- Scoped app → XMLDocument2.getNodeText
- Global scope → GlideSystem.getXMLText
- Both require an XPath expression
🧪 REST API Explorer: Constructs and tests API requests against your instance, listing endpoints, methods, and variables, then supplies code samples in multiple languages once the request is configured.
MID Server Essentials
Line of Sight
- Direct network connection to the target
Credentials
- Access to execute the task on the target
Access to ServiceNow
- HTTPS (443) or an internet proxy gateway
MID Server Configuration & Tuning
Fault Tolerance
- Load balancer / fail-over cluster, matched capabilities
Network Connectivity
- Deploy in the same subnet as targets to avoid extra routing/firewall hops
Threads
- Default 25 concurrent — raise to increase parallel task capacity
JVM Memory
- Default 1GB — increase alongside thread count
File Transfer: FTP vs SFTP
FTP: Not encrypted, not secure. Achieving security requires a VPN tunnel — which ServiceNow cannot arrange itself.
🔒 SFTP: Runs over an SSH session via Port 22 — secure and encrypted. Authentication is username/password or public/private key based.
Common Integration Scenarios
Import Users from AD
LDAP/S via import sets & transform maps on a scheduled job. Modify the transform map to lock out users deactivated in AD — track the "updated" field to catch stale accounts.
MID Required
Legacy System Email Alerts
Legacy system sends an alert email; an Inbound Action captures subject/body content and creates or updates a task record — e.g. a critical event generating an Incident.
MID Not Required
MS SQL Server Data Collection
JDBC data source with server & credentials, linked to an import set/transform map. Key questions: trigger frequency, and what provides line of sight.
MID Required
3rd-Party Web Service Data
Outbound REST/SOAP service message on a scheduled job, parsing the XML/JSON payload into an import table via a transform map — e.g. public economic metrics.
MID Not Required
Enterprise Service Bus (ESB)
✅ Fewer changes needed to ServiceNow and the target system
✅ Can integrate with more systems more quickly
✅ Cloud access is likely already available
❌ Another system in the mix with its own requirements
❌ A third group developing the integration can add time & complexity
❌ Baseline spokes may need customisation to fit ESB APIs
Examples: Microsoft BizTalk · MuleSoft Anypoint · Cisco ServiceGrid · RabbitMQ
Digital Certificates
What It Contains
- Public key (never the private key)
- Identity of the owner
- Valid-to date
Purpose
- Establish an SSL connection
- Enable encrypted communication
- Provide transaction authenticity
💡 Example: Establishing a secure LDAPS channel to a company's AD server — ServiceNow certificates are verified by Entrust; customer certificates can be self-signed and must be uploaded per LDAP server.
Custom Integration Considerations
1
Two halves — effort is needed on both the ServiceNow side and the remote system side; engage product-specific expertise for the remote system2
Custom & specific design — a customer architect should sign off the design; what's built must also be maintained, so keep it as simple as the requirement allows3
ServiceNow does things differently — the remote system will likely need adapting; leading practices may mean rethinking how it's "always been done"1
Build vs buy — prefer existing ServiceNow/partner store functionality; custom solutions require continual maintenance and dedicated technical resource2
Evaluate your approach — scope frequency (batch vs real-time), data specification, transaction specification, and integration channel3
Set up an interface agreement — document the business process supported, the operation & data interchanged, and how updates/upgrades stay in sync4
Sync only relevant data — extract just what's needed at the source; cleaning up bad data after import is far harder than fixing it upstream5
Manage performance — run large loads off-peak, watch the semaphore count, load-test, and use staging tables for on-demand validation/transform6
Monitor transactions — track active/completed/failed transactions, execution time, and system load via import tables and transform map logging7
Use Correlation IDs & IRE — track the source system and its record identifier on the task table to cross-reference records and prevent duplication8
Focus on data security — dedicated non-GUI integration accounts, scoped ACLs/roles, firewall rules, DMZs, and secure protocols (HTTPS, LDAPS)9
Handle errors & retries — log centrally, classify errors, notify only on mission-critical failures, and retry connectivity errors (never data errors)
🔑 Part 1 Takeaways: Evaluate methods, options & protocols against architecture and maintenance needs · Lean on IntegrationHub for fast, low-code automation · Follow leading practice on data strategy, security, performance & error handling.
Five Foundation Data Elements
People
- Consumers of services — staff & customers
- Imported from an Identity Management platform
- Unique identifiers: LAN login, employee ID, email
Company
- Legal entities — distinct from "organizations"
- Load using legal entities; hierarchy via parent structure
- Normalization Data Services reconciles name aliases
Organizational Structure
- Departments & business units, parent hierarchy
- Load department data from the financial system
- Restructures can take ~3 months to fully reflect
Location
- Geographical data meaningful to processes
- Hierarchical: country → state → city, ISO-based
- Often poorly mastered unless core to the business
Groups
- Assignment · Permission · Process · Approval · Notification
- Leading practice: never assign roles to individuals directly
- Personas parent process groups for RBAC inheritance
Guiding Principles for Foundation Data
1
Foundation data is any data element on the platform that supports a capability2
Configuration shapes value received, effort to manage, and onboarding time for new capability3
Data can be sourced externally as long as it stays timely4
Good governance is required to keep data complete, accurate, and current5
Ownership is critical — foundation data deserves its own product ownerFoundation Data Governance
Control
- Model via service catalog items with core-data-owner approval
Ownership
- A single product owner sets strategy per data element
Auditing
- Regular certification via CMDB Health / Data Certification
Monitor Data
- Periodic health scans for inactive users/groups via last-login reports
Who / What / Where Shapes the Service
Who
- The consumer's role shapes the service they receive
What
- Services sit in a structured Service Catalog hierarchy
Where
- Location brings language, culture, region, and local time into play
CSDM Service Types
Business Service
Published to business users; underpins one or more business capabilities, delivering specific value and outcomes.
Technology Management Service
Formerly a Technical Service; provides the admin/operational functions to manage technologies layered under business services.
Service Instance
Formerly an Application Service; the instantiation of a service.
🎟️ Service Offering: Every service needs at least one offering to reach the catalog — SLAs and metrics (performance, availability, subscriptions) are defined at this level, not the service level.
SPM Metrics
Activity
- Fulfilled request items from catalog items
Availability
- Calculated from outage records
Breached SLAs
- From service offering SLA commitments
Customer Satisfaction
- Tabulated from subscriber surveys
Stability
- P1 + major incident counts combined
Custom Metrics
- Bespoke service offering performance indicators
Choosing an Integration Pattern
Bulk Import
- Scheduled, usually daily, into an import set
- REST/SOAP push, or MID server via JDBC/LDAP/FTP
Bulk Export
- HTTP web services (CSV/XML/JSON/Excel), ODBC, export sets
- Third-party replication tools (SnowMirror, Perspectium) for DW/lake
Transactional — Outbound
- Business rule/script triggering a REST or SOAP call
- Flow Designer + IntegrationHub spoke
Transactional — Inbound
- Table REST/SOAP APIs, scripted web services
- Inbound email actions (create/update via import set)
User Authentication & SSO
📇 LDAP Directory Sync
Authenticates against the source attribute — "ldap" prefixed values validate via the LDAP server; otherwise the ServiceNow password is used. Requires direct line of sight (or an IPSEC VPN tunnel) — the MID server cannot be used for real-time authentication.
🪪 SSO / SAML Sign In Once
An Identity Provider (ADFS, OKTA, Oracle SSO) exchanges XML-based SAML assertions with ServiceNow. Either IdP-initiated (user clicks through from the IdP) or ServiceNow-initiated (user hits ServiceNow first and is redirected to authenticate).
🔑 Part 2 Takeaways: Foundation data underpins every capability — govern it with clear ownership · Use CSDM & SPM to structure services · Match the integration pattern (bulk vs transactional) to the data's volume and urgency, and use LDAP/SSO to simplify user access.
Takeaway 01
Match Pattern to Purpose
Cloud, point-to-point, and MID server integrations each solve a different access problem. Choose the pattern based on line-of-sight and firewall constraints, not habit.
Takeaway 02
IntegrationHub First, Custom Last
Store apps and IntegrationHub spokes should be the default. Reach for a custom build only when no baseline solution exists — and budget for its ongoing maintenance.
Takeaway 03
Foundation Data Is the Prerequisite
People, Company, Organizational Structure, Location, and Groups must be governed and accurate before Service Portfolio Management or any downstream integration pattern can be trusted.