1. Implement integrations with ServiceNow
Success Pillar: Get your ServiceNow technology foundations right

2. Success Pillars – Structure
State and measure your business goals
Actively lead the transformation
Get your ServiceNow foundations right
Create excitement, drive adoption 1
State your transformation vision and outcomes 1
Engage an executive sponsor to drive change and remove roadblocks 1
Manage to
out of the box 1
Design an engaging self-service employee and customer experience 2
Build your business case 2
Find, manage, and coordinate capable, certified partners 2
Discover and map your service assets 2
Design an optimal agent and rep experience 3
Build a phased
program plan, identify quick wins 3
Build a dedicated, dynamic governance process, policies, and team 3
Plan your architecture, instances, integrations, and data flows 3
Create a change management plan 4
Baseline and track performance, usage KPIs, and metrics 4
Reimagine how you want work processes to flow 4
Plan for upgrades at least once a year 4
Build an internal team of ServiceNow experts and train users 5
Define and map out your business services 5
Build a community of champions 6
Manage platform demand

3. Implement integrations with ServiceNow
Integrations allow two systems to exchange data to facilitate end-to-end processes and provide visibility to key information across systems. Data can include information—files, users, groups or managers, or instructions—for a system to carry out various functions, such as orchestration. 
ServiceNow® is capable of both sending data to or receiving data from an external system. It’s a web-based application, and it natively supports common internet protocols like REST and SOAP, among other technologies which vary in complexity and flexibility. The level of effort in an integration depends on many factors, including the technologies involved, security requirements, and the type, frequency, and amount of data to be transferred.
Once you determine that an integration is necessary, make sure to include business and technical parties from both systems and start a conversation about the value that the integration will bring and any significant limitations that either system may have. This initial pre-work will set up you for more efficient technical design and implementation. 
Insights: Implement integrations
Consider the following key insights before starting your integration implementation:
Your integration with ServiceNow® should deliver tangible value and support your business outcomes. Carefully consider if the value of the integration outweighs the initial implementation and ongoing maintenance costs. Some integrations can be replicated with workflows in ServiceNow that deliver equal value with lower long-term cost.
Identify the process owners, administrators, and other stakeholders from ServiceNow, as well as third-party vendors who will support the integration implementation. These experts should be involved in scoping your integration needs and assessing the system capabilities, including finding any limitations (e.g., performance load, VPN, or middleware needs, etc.), prior to technical design.  
Default to using standard, predefined integrations in the ServiceNow Store or IntegrationHub. Custom integrations take longer to implement, and you’re responsible for their long-term maintenance.
Revisit any preexisting integrations to ensure alignment and minimize the risk of data duplication or overly complex workflow design.
Key implementation steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

4. Step 1a: Determine your integration needs
Think critically about whether it makes sense to integrate ServiceNow with another system prior to technical design and implementation.
Define your end goal in integrating ServiceNow with another system
What are you trying to achieve with ServiceNow or an external system by having them integrate, i.e., what value will the integration deliver?
Common integration use cases include:
Process integration – Synchronizing data automatically across ServiceNow and another system to inform ongoing processes completed in either system (e.g., using data pulled from an external system to inform ITSM processes managed on ServiceNow or sending ServiceNow records to Jira to create development stories)
UI integration – Integrating ServiceNow with a public web source to present information on the user interface that will support process users and end users in processing a record (e.g., displaying the weather forecast or office locations on a map)
Data integration – Enabling data sharing/movement to improve or enable processes and applications managed on ServiceNow (e.g., integrating ServiceNow with an HR application so you can use HR data in fields on ServiceNow)
Does this integration support a key business objective?
Who will use the output of the integration? How often?
What pain points does the integration address? How does it improve existing processes?
What is lost by not integrating? Consider whether the benefits of integrating exceed potential maintenance costs (e.g., error handling, regression testing after upgrading).
Could you deliver the same capability/value by replicating the workflow in ServiceNow instead of integrating? We recommend using this as an opportunity to rethink your workflow and reduce unnecessary integrations.
Practitioner insight: Well-designed integrations can be simple to implement but add complexity to your environment. For this reason, we always recommend starting with an open conversation about if and why you truly need the specific integration you’re considering. As you design your integration, continue asking yourself “Are the systems we’re integrating all needed, or can this work be done more simply within one system?”
Involve the following stakeholders in determining your integration needs and planning in Steps 1a and 1b:
Now Platform owner and executive sponsor (and other leaders, as needed)
Administrators for third-party systems you want to integrate with ServiceNow
Process owners of processes impacted by the integration (ServiceNow and external)
Integration expert (if available)
Enterprise architecture representatives
Certified partners and/or ServiceNow Customer Outcomes team
ServiceNow account team (including your solution consultant)
Steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

5. 1. Define your integration needs
Step 1b: Map how your integration will work
Now that you’ve identified your integration goals, start with high-level process and data mapping to inform your technical design. You should conceptually understand the process work that happens in both systems as well as the data required for that work.
Design and document the workflow across the systems involved in your integration
Which systems do you need to integrate with ServiceNow to accomplish your desired outcome? 
What type of systems are they? How do they work?
Are they point-to-point integrations or will you go through an enterprise service bus (e.g., MuleSoft)?
Who owns these systems? Are the system owners involved in your integration planning? (If not, they should be).
If it’s a process integration, what are the process steps on each side of the integration?
Validate the process steps in each of the systems you’re integrating.
Are there any process dependencies across systems that you need to consider when designing your steps?
Which direction will data flow? From ServiceNow, to ServiceNow, or bi- directionally? How does the lack of data affect your process?
Determine what data is needed to enable what you want to do on ServiceNow and/or an external system and define how relevant data is distributed at a conceptual level
Identify the types of data from external systems or ServiceNow that needs to be in place, both initially and ongoing. For example, if you intend to use manager data from Workday to drive ServiceNow processes, managers must be maintained in Workday long term.
Identify the system of truth for each data type so you can make sure data stays in sync across integrated systems. Will this remain on the integrated system or be maintained on ServiceNow post-integration?
Make sure that the data is read-only outside of the system of record.
Evaluate the data that you’re considering integrating.
What specific data fields are available? Is there a data sample you can look at?
What user attributes do you need to support the process/work you enable via integration? For example, if you pull user data into ServiceNow to support change management but the change approval process requires manager approval, you also need access to manager information.
How does the data you’re integrating support your defined process? Prevent duplicate data issues by only transmitting the minimum data required.
Practitioner insight: Process design for integration is an opportunity to hit the reset button on your existing way of doing work. Evaluate whether your existing process and/or an older integration that you’re now replicating can be improved to meet your business objectives.
Steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

6. 2. Design your integration
Step 2a: Prepare for your integration implementation
Nearly all ServiceNow customers find additional value by integrating with third-party applications. The most common third-party integrations are with CMDB, Incident Management, Problem Management, Change Management, User Administration, and Single Sign-On. You can use a variety of techniques but always gather accurate requirements—measure twice and cut once—to design and develop effective integrations.
Understand ServiceNow integration technologies
Web services
File retrieval/import sets
JDBC connections
LDAP
REST and SOAP (REST is recommended)
Excel, CSV, and
MID Server – API and command line integrations
Involve the right people with the technical skillsets needed to design the integration in Steps 2a & 2b, including the following stakeholders:
SMEs for each system involved in integration
Integrations expertise
Data architect
Administrator of third-party systems you want to integrate with ServiceNow
Enterprise architecture representatives
Security
Certified partner and/or ServiceNow Customer Outcomes team
ServiceNow account team (including your solution consultant)
Consult with your enterprise architecture and security teams to define integration requirements
Identify the preferred tools and methods relevant to integration. For example, web services, data transformation tools, APIs, etc.) and organization standards. Different integration technologies have pros and cons. Consult a certified partner and/or your ServiceNow account team to determine which integration technology is best for your use case.
Identify current integrations related to the systems you plan to integrate with ServiceNow (including preexisting integrations). Determine if/how these integrations might impact your new integration.
Determine any performance load limitations and how you will conduct load testing. For example, what is the maximum number of records that can be processed at once, the pagination strategy, etc.
Coordinate integration and architecture requirements: tables, fields, and data relationships. Consider any related security requirements, such as table ACLs, service accounts, and roles.
Address security requirements/concerns related to the integration. Is security comfortable with sharing and storing data on ServiceNow? 
How will data be authenticated? Is basic authentication via https sufficient (TLS encryption) or do you need Oauth or something else?
Steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

7. 2. Design your integration
Step 2b: Determine your integration method
Customers have many technologies and methods to manage integrations between ServiceNow and external systems. Always look for configuration options first, starting with ServiceNow-supported integrations or those available on the ServiceNow Store. If you need custom integrations, contact your ServiceNow account team or build your own integration using the platform’s integration capabilities. Check with your ServiceNow account representative about licensing.
Select the best ServiceNow integration from the options below, listed in order from the most supportable to those that provide the most flexibility/choice
ServiceNow Store integrations (for example, DocuSign, Box, Slack, xMatters) – These integrations are built by ServiceNow or a partner that’s an expert in the external system. The seller of the integration will generally provide implementation and ongoing support.
IntegrationHub (for example, MS Teams, HipChat, eBonding for multiple ServiceNow instances) – Used primarily for outbound integrations from ServiceNow, IntegrationHub offers several pre-built spokes than give you automation capabilities in a single system of action.
Integrations previously built and supported by ServiceNow product teams outside of IntegrationHub (for example, Active Directory and PowerShell as part of Orchestration) are actively being migrated to the ServiceNow Store or as pre-built spokes within IntegrationHub.
Note: Not all integrations on the ServiceNow Store will be spokes compatible with IntegrationHub. Use the IntegrationHub filter when in the ServiceNow Store to filter integrations specifically designed for use with IntegrationHub.
Custom (REST, SOAP, IoT devices, file import and export abilities via CSV or XML, Flow Designer with IntegrationHub) – Custom integrations meet a specific customer use case, are designed from scratch, and are owned and maintained by the customer long-term.
Practitioner insight: Use as much out-of-the-box functionality as possible in the initial deployment, unless it’s absolutely critical to build a custom integration. Otherwise, avoid customized integration until the platform is adopted and your process users trust it. ServiceNow provides several interfaces that let you directly integrate with the platform. These interfaces are considered part of the platform and are provided at no additional charge. You can find list of supported integration interfaces in the ServiceNow product documentation.
Practitioner insight: Set expectations around how much effort will be involved in implementing the integration and supporting it long-term, based on the use case and technical requirements. This is especially important for custom integrations. Integration owners need to understand the effort required to build and manage their integration before implementing it. Standard integrations, such as those available through the ServiceNow Store and via spokes in IntegrationHub, will take less time and effort to implement.
Steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

8. 2. Design your integration
Step 2c: Define technical requirements
Define how the systems will connect to each other and how data will be transmitted between them (i.e., the network path)
Where is the data and is it available to the internet? ServiceNow typically doesn’t have direct access to on-site infrastructure so it maybe be necessary to use a proxy to connect (e.g., MID Server* or tunneling through with a VPN). Integrations are simplified if the data can be made available on the internet.
Is the system you want to integrate with capable of integration with ServiceNow? Some older systems (e.g., mainframes) don’t easily support ServiceNow integrations. 
Do you have any security concerns that could make data transmitting more difficult (e.g., firewalls)?
What technique (language) will the two systems use to talk to each other (e.g., https) ?
How will errors be handled? Who is responsible for resolving errors? What monitoring or logging will be required? Is any middleware required? 
Explore details about the data you intend to transmit data across systems
How and in what format is the data available? An example data mapping architecture is available in the appendix.
What is the data quality like? Does it need to be transformed prior to applying it?
How frequently should data be transferred/synced (i.e., in real-time or batches)? While some cases require real-time exchange (e.g., some process and all UI integrations), most data transfers should be asynchronous to limit effects on system performance. Consider potential time zone impacts if your instance is global.
What is the volume of data transfer (e.g., estimated number of transactions and their size)? Work with your enterprise architecture team to ensure that the system(s) can handle your expected volume.
How does data need to be packaged?
Identify the events that will trigger an exchange of data between systems
What are the triggers for the process? This could be events—such as creating an incident or assigning it to a particular group—when certain fields such as Priority are changed, when a work note is added, etc.
Will you always send/receive all records or only the delta between records since the last synchronization (i.e., a “changes only” file). We recommend transmitting only the delta between records instead of sending all records, when possible, to minimize system performance impacts.
Will ServiceNow and/or the external system push or pull data? Pushes tend to be more real time and transactional in nature. You always need to batch pull triggers.
*The MID Server is a Java application that runs on your local network. It facilitates communication and movement of data between the Now Platform® and external applications, data sources, and services. The MID Server always initiates communication with the ServiceNow instance, not vice versa, adding a layer of security.
Steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

9. 2. Design your integration
Step 2c: Define technical requirements (Continued)
Follow these best practices when you create integrations:
Integrations come in two halves—one for each system. Make sure your resources have the necessary expertise to implement their half.
Define business rules to extract only relevant data from source systems and don’t pull in more data than you need. Validate which data is transmitted with your executive sponsor and business owners to make sure you’re capturing the data necessary to achieve your end goal.
Execute large integration loads after hours or during a non-peak time of day to minimize performance impact to your systems.
Use out-of-the-box features and functions as the baseline, especially the ServiceNow API.
Use IntegrationHub (requires a separate subscription) for designing custom integrations. IntegrationHub extends the ServiceNow Flow Designer to incorporate integrations into automated processes.
Work with a certified partner when you build custom integrations unless you have strong, ServiceNow-specific integration expertise within your organization. The right expertise can dramatically simplify work and even reduce total investment (by reducing the need for rework). 
Consider our internal, customer, and partner learnings when you design your integration.
Practitioner insight: Implement ServiceNow functionality so that users can't make changes to a record that impacts the integration. Lock fields (e.g., updating the state field directly) on forms as needed. Users not allowed to make updates can use journal fields, such as comments and work notes instead. 
Practitioner insight: Customers engaged in enterprise services transformation will see more demands for cross-platform integration, but this doesn’t necessarily have to lead to complex, customized integration. ServiceNow’s IntegrationHub reduces the need for complex, custom-coded integrations because you can execute third-party REST APIs as part of a workflow when a specific event occurs in ServiceNow. IntegrationHub supports three use cases, reducing the need for custom code:
Third-party REST API integrations – Customers can post messages and ServiceNow incident, problem, and change record details to collaboration channels like HipChat, Slack, or Microsoft Teams.
Integrations between ServiceNow instances – IntegrationHub provides an easy-to-configure spoke allowing data synchronization across multiple ServiceNow instances.
Creating REST actions – IntegrationHub supports developing custom REST web service actions to support API development for web-based applications.
Steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

10. 3. Implement your integration
Step 3: Implement your integration
Start with a pilot and conduct unit and end-to-end testing to iterate
Develop a simple proof of concept (POC) by completing the minimum configuration necessary in each system.
Start by manually “transmitting” fake data—in other words, manually uploading a file—to determine if the receiving system understands it. Separating process and data movement or transformation will reduce your initial testing time.
Run an end-to-end test across both systems using a real-life use case and include all impacted users. Make sure to account for different process scenarios in your testing, if applicable.
Conduct a load test to ensure the integrated systems can handle the maximum expected number of data records. Notify your ServiceNow account team prior to conducting load testing to prevent an unintended security response.
Take a trial and error approach, minimizing adjustments with each test to identify the root of issues. Iterate your integration based on test results.
Consider available debugging resources, such as enabling session debug.
Activate your integration and maintain it long term
Determine a strategy for error handling, monitoring, and logging.
Formulate an ability to review and monitor errors. For example, consider using middleware products for monitoring items such as system load, failed transactions, and execution time.
Log all errors to a centralized location, creating notifications for mission critical errors.
Classify your errors for future process improvement. These might be technical, unexpected, user error, etc.
Complete regression testing against new releases.
Did any of the processes that affect the integration change?
Were any system capabilities added, removed, or changed?
Periodically evaluate whether the integration is still necessary and if you can improve the process on either integrated system.
Practitioner insight: Troubleshooting and debugging can be difficult, depending on the technology and language involved in the integration. Some implementers also lack maturity in integration troubleshooting. Regardless, few integrations are perfect after the first try. Follow these guidelines for troubleshooting:
Source partnership from a ServiceNow integration expertise, either from a qualified partner or from ServiceNow directly.
For direct web services integration (not through a MID Server), troubleshoot programmatically in catch blocks.
Use Now Platform capabilities like the retry policy capability to support troubleshooting, especially when you’re working through a MID Server.
Once the integration is set, it tends to continue working unless something happens network-wise or when integrated systems undergo changes/upgrades. Make sure to conduct thorough integration testing when you upgrade either your instance of ServiceNow or your external system.
Steps
1. Define your integration needs
2. Design your integration
3. Implement your integration

11. Example data mapping architecture
Source field
Target field
Format
Transformation?
Coalesce?
Example: Users from Active Directory
samaccountname
user_name
String (< 16 chars) No
Yes
userprincipalname
name
first_name, last_name
String
Split data on space
Example: CIs from Active Directory id
asset_tag
serial
serial_number
Numbers
Reject CI if invalid/blank
created
installed
yyyy-mm-dd

12. Integration attributes to consider reviewing
Trigger
Message
Protocol
Timing
# Records
Translator
Response
Security
Business rule
JSON
REST
Real time
Single
ServiceNow
Synchronous
None
Workflow
XML
SOAP
Near real time
Batch
Middleware
Asynchronous
Basic
Schedule
File
SFTP
Scheduled
Delta
Endpoint
Oauth
Event
Full
Token
Script
SAML 2.0
Manual