Why a Native Application for ServiceNow Integrations?

When you run an integration with a ServiceNow native application, you can manage your integration from within ServiceNow. There’s no need to learn or switch to another application or platform. 

Once the integration application is installed as a ServiceNow update set (or directly from the ServiceNow store), you can configure the data flow.

Such an app helps you maximize the value of your ServiceNow investment for a number of reasons.

1. Familiarity for ServiceNow Admins

The ServiceNow admin is already comfortable in the ServiceNow environment. A native application is just another application in their left-hand navigation.

This means that admins can get to work quickly on setting up and modifying dynamic or bulk shares, following publicly available documentation.

2. Expertise Verified by ServiceNow

ServiceNow applications found in the ServiceNow app store are pre-built and pre-tested by ServiceNow Technology Partners.

And importantly, these apps are certified by ServiceNow for security, performance, and compatibility.

3. Security and Privacy

Even as dynamic transfers take place in near real time, a ServiceNow native application such as Perspectium DataSync communicates indirectly with the other endpoint via the Perspectium integration mesh. This architecture enables control over essential security features.

No Sharing of Credentials

With a native application, there are no web services using login credentials to access your ServiceNow instance, because data is not being pulled from a receiving system. The ServiceNow admin does not need to provision any Access Control Lists (ACL). So the integration does not require any user account management.

Control Over Data Flow

The publish-subscribe method allows the ServiceNow admin to have full control over which data is exported and made available. For example, your HR team may want data sent to their own database. And your server team wants ticket data sent to their database. The native application lets you set up data flows for different queues, sending the data to different locations.

The ServiceNow admin also maintains control over who and what is allowed to modify instance data when ServiceNow is on the receiving end of the integration.

End-to-end Encryption

A native application gives you the ability to encrypt data at the source before it leaves the instance. Customers alone view, own, and control the encryption keys. The integration service provider has no way of accessing the encryption keys.

Data Obfuscation

The ServiceNow admin hides or obscures sensitive information before it is made available. Data can be obfuscated by field, by pattern, and by reference. Data obfuscation helps companies stay in compliance with GDPR and other privacy regulations.

4. Throughput With Lower Impact

ServiceNow customers commonly seek out a native-application solution for integrations to reduce impact on ServiceNow performance.

The Performance Impacts of Web Services

So what’s happening without a native application? When ServiceNow customers run reports directly on ServiceNow using APIs, they incur performance impacts. These slowdowns happen especially when data volumes grow. The more data an organization has, the more web-service calls that are being made. 

The reason for larger performance impacts is that web services compete with browser sessions, acting the same as any web browser user trying to get to the same information. Web-services integrations often use an all-or-nothing pull, hitting ServiceNow with crippling performance impacts.

So the reporting jobs themselves are slow. And they slow down ServiceNow for users across the organization. ServiceNow users who don’t see a response from ServiceNow re-try their activities, creating further impact on ServiceNow.

But if you have a copy of ServiceNow data that is outside of ServiceNow, you can report on that external storage without having any impact on ServiceNow.

ServiceNow is an engine. As long as you add any interaction to an engine, there’s going to be added friction. That performance impact can range from drastic to negligible.

A native application minimizes performance impact during data extraction for multiple reasons. 

Lower Impact Through Push Technology

A native application, because it’s already installed into the ServiceNow system, can notice when records change – and push payloads of changed records to a message bus. Push technology empowers the best possible throughput.

Lower Impact Through Load-Balancing

Performance stays strong with a native application because a ServiceNow admin uses a native application to load-balance the integration. (Ok, this gets more technical.) ServiceNow is a multi-node cluster, but not all nodes are equally used in a cluster. Some may be actively used, while others are just standing by.

Using push technology, a native application can make use of those non-active nodes, load-balancing to maximize performance. This arrangement removes the impact from those who use the ServiceNow platform on a daily basis.

Lower Impact by Throttling the Rate of Posting

Another reason that performance stays strong is that a ServiceNow admin can decide when the native application will publish selected data. If data volumes are especially high, that admin can use a staggered approach to publish data via HTTP POST to databases or other instances, where teams can engage in otherwise performance-impacting jobs away from the production instance.

For example, ServiceNow admins regularly receive requests for data. In addition to identifying fields, timing, and frequency for the integration, they are also in a position to identify which time slots are regularly available for the delivery of large batches of data.

5. Availability Ensures Data Integrity

An integration should be able to function in the face of power and network outages. With most web-services integrations, if an endpoint is down, the data in transit ends up lost.

A native application, however, can push data into queues. The data deletes after being consumed by the subscribing endpoint – but only if that endpoint is online. If the target endpoint is down, data sent via a native application stays in the queue, available to be consumed whenever the endpoint is ready again to receive data.

6. Real-time Data Flow

A native application has instant access to business rules and flow. This immediacy enables real-time triggering of data workflow – and near real-time data publishing and delivery.

7. Delete Detection

Data changes include deletions. The “Right to be forgotten” is a requirement within GDPR. A user can request that personal data be removed, or a company may identify workflow data as inappropriate for storage. Deletion of ServiceNow data is triggered only in ServiceNow, and cannot be achieved through a web-services call.

When you’re managing an integration from outside of ServiceNow, you have no way of knowing when a record is deleted. If, for example, a change request is replicated to a reporting database and subsequently deleted because it was created in error, only a native tool (like Perspectium DataSync) is able to identify the deletion, and ensure that the record is removed from the reporting database as well – thus preventing bad data.

8. Referential Integrity

With a native application, a ServiceNow admin can move data in context, helping to ensure that related information stays in sync. 

For example, you may wish for a replicated incident to look and act in the target system exactly as it did in the original system. Along with the ticket, you would need for the CI and the user details to transfer as well, appearing in all the correct fields. Because of referential integrity, the integration saves time and improves the user experience for desk agents.

9. Data Transformation

When replicating data, a ServiceNow admin often transforms data, making it usable in other tools. Sometimes, data transformations must occur when systems are upgraded, or when data is moved from a domain-separated ITSM instance to a standalone instance or vice-versa.

With a native application, you can configure a table map directly in ServiceNow, making sure that the data transformation takes place prior to publishing.

Get a Head Start on Results Through Rapid Implementation

Really, when you make use of an existing solution via a native application, what you’re doing is accelerating your time to value.

The DIY approach can take months. Our research revealed that it takes ServiceNow customers an average of 370 hours to build their own integration. Customers that take the DIY approach then end up spending almost the same amount of time each year to maintain their integrations through upgrades and process changes. 

Implementing with a native application will still take some time, but enterprises frequently opt for a native application to bypass the additional months of development time.

Want to try it out? No form to complete – try a hands-on demo now of the Perspectium DataSync native application.