ServiceNow Integration with Salesforce: Secure Two-Way Sync with Peeklogic Connector

ServiceNow integration with Salesforce is done by hand in most companies. A customer reports a problem, your agent opens a Salesforce Case, then logs an incident in ServiceNow for IT.

Three days later the customer calls for an update. The Case looks exactly as the agent left it, because everything since then happened in ServiceNow. So she asks IT on Slack.

Nobody planned it this way, but the two systems were bought by different departments, in different years, for different jobs. That is the normal state of things. Salesforce’s Connectivity Benchmark Report 2026 counts 957 applications in the average enterprise, and only 27% of them are integrated with each other.

The first fix is usually a script. An admin writes an Apex class that checks ServiceNow at regular intervals and copies the incident status into a field on the Case. It works until IT renames a status, and then it copies the wrong value for a good while before anyone even notices.

Scripts like that keep breaking for these kinds of reasons, even though the code itself is solid. Let’s look at why that happens, and what your options then are.

Why Salesforce and ServiceNow Stay Separate

Your CRM holds the customer: the contract, the renewal date, the account owner, every complaint on record. ServiceNow holds the infrastructure: the incident, the queue, the SLA clock, the engineer on shift. Both systems describe the same event, but neither one knows the other half of the story.

By default, nobody closes that distance (or a person does, by keeping two tabs open).

Salesforce State of Service found that 58% of agents at underperforming service organizations toggle between multiple screens to find what they need, against 36% at high performers. That 22-point gap is built out of hundreds of tiny delays. A hundred tickets a week turns into an hour of pure tab-switching.

Visibility across teams suffers along the way: your sales team cannot see whether an open incident threatens a renewal, and support cannot tell a customer when a fix lands. Issue resolution slows down, and the customer experience suffers.

Three Ways to Connect Salesforce and ServiceNow

There are three real options when you integrate Salesforce with ServiceNow, and the choice comes down to how much engineering time you have and who you expect to maintain the result two years from now:

Obviously, those rows differ on launch speed. But even more, they differ on where the integration logic is stored: in your repository, on someone else’s server, or inside your own Salesforce org. That decides who you call at 2am when the sync stops.

There is a fourth route worth naming that starts on the ServiceNow side. ServiceNow IntegrationHub builds the connection from the ITSM side, which puts your synchronization in the hands of the team that administers ServiceNow, and by Unito’s own account it leans on scripting and a one-way data flow.

All three options in the table streamline the same manual work. They differ on what you own afterwards.

Custom development looks cheapest at the start, because you only ever see the first invoice. The second one arrives with every ServiceNow release.

How Peeklogic Connector for Salesforce ServiceNow Integration Works

Peeklogic Connector installs as a package inside your own Salesforce org from AppExchange. Authentication runs on Salesforce Named Credentials, so logins and tokens sit in the platform credential store instead of in code or custom settings. Basic Auth is supported, and the mechanism is ready for newer standards.

Calls to ServiceNow execute asynchronously, so Salesforce performance holds steady during data transfer. When an agent saves a Case, she is not left waiting on a ServiceNow response, and your synchronous callout limits stay free for other work.

The connector reads and writes the standard ITSM tables, Incident, Problem and Change Request, along with custom ServiceNow tables. You choose which tables to expose during setup, then pick specific fields inside each one.

One more thing worth planning at the start. The connector holds several connections to different ServiceNow instances at once, and one of them gets marked as default; every form, automation and connector action uses that one until you say otherwise.

For companies running separate ServiceNow instances for dev and prod, that removes the most common cause of ruined data. Test automation that created twenty incidents in the live instance.

What Syncs, and In Which Direction

Bidirectional synchronization means at least three different things depending on who is selling it. In Peeklogic Connector, records flow one way, incident data is read live the other way, and comments travel both ways.

Notice the second row: ServiceNow data gets fetched when the page opens, so Salesforce never accumulates a second, slightly wrong version of the truth. What your team reads is the real-time state of the incident, as it stands in ServiceNow at that moment.

Your admin decides which ServiceNow columns appear in that component: State, Priority, Short Description, whatever the team needs on screen. The point is to unify what both sides see into one cohesive view across both platforms, without copying customer data into a second system.

So an account manager reads incident status from the Account page without holding a ServiceNow license. That, frankly, is the whole point of the exercise.

Salesforce Integration Setup: From Install to First Sync

Median setup time across Peeklogic connectors is 30 minutes, based on internal data from more than 500 implementations. The sequence is short:

• You start on the Salesforce side and create Named Credentials for both ends, one for ServiceNow and one for Salesforce. Then open the Peeklogic ServiceNow app from App Launcher and go to the Peeklogic Setup tab.
• In Setup Connection you click Create New, name the connection, select both credentials, and tick Is Default if this is your primary instance.
• Project Settings is the one step that needs thought. Every table on the connection shows by default; you keep the ones your team will use, save, then open each table on its own and select the fields that should be available.
• Related List Layouts comes last, and that is where you define which ServiceNow columns the end user sees in the component on a record page. The same app carries a Support tab, so an admin sends logs or questions to the support team without collecting them by hand.

Workflow automation needs no code here. The connector ships an Apex Action called Create/Update ServiceNow Record, and you drop it into an ordinary Salesforce Flow to automate the handoff: if Case priority is high, create an Incident in ServiceNow. One Flow element gives you a smooth data flow between the systems, reducing manual ticket-raising for your agents.

An admin builds that Flow, and most of the savings hide in exactly that. Changing a rule, say adding Priority = Medium to the trigger conditions, takes five minutes with a mouse.

In a custom build the same change becomes a backlog ticket, a branch, a code review, a deploy and a regression pass. The change itself is equally simple either way; the difference is how many people it wakes up.

Named Credentials and Your Security Perimeter

Security review asks the same two questions every time. Where are the credentials stored, and who else sees the data in transit.

Peeklogic Connector uses Named Credentials, the standard Salesforce mechanism. Secrets are stored at platform level with Salesforce handling encryption, and the connector code carries no hardcoded tokens. Rotating your ServiceNow password happens in one place and touches nothing in the integration logic.

Access controls run through the Salesforce profiles and permission sets you already maintain. A user reaches ServiceNow data through the connector only on records they could already open, which keeps your review scoped to a permission model your admin knows.

Peeklogic holds ISO 27001:2022 certification along with HIPAA and GDPR compliance. If your security team is assembling a vendor assessment pack, those attestations can be requested directly.

Custom Build Versus a Ready-Made Connector

Estimates for a custom integration almost always cover the first third of the work. You count the Apex classes, the API calls and the field mapping, produce a number, and get the budget approved.

The second third is what nobody prices at estimate time: error handling, retries when ServiceNow times out, a queue for failed requests, logging, permission models, behaviour under bulk updates. The third part never ends, of course, because ServiceNow and Salesforce ship releases on their own schedules and your integration has to survive each one.

A ready-made connector gives you a figure you can see in advance. You pay for a package instead of sprints, and you avoid keeping one person on staff who alone understands why the status mapping was written that way.

A demo beats a price list here, because half the decision depends on how your ServiceNow tables are structured. Custom tables and non-standard incident states surface in about five minutes of conversation.

The other half depends on volume: how many records pass through the integration daily, and whether large volumes of data arrive in spikes. That is also faster to show than to describe.

Where This Fits, and Where It Does Not

The connector lands best where Salesforce is the primary workspace for a team that holds no ServiceNow licenses. Support, customer success, account managers: people who need incident status without access to ITSM itself.

A second fit is companies where a separate IT team administers ServiceNow on its own processes. Nothing on their side needs rebuilding, since the configuration stays on the Salesforce end.

Now, if you need a state change in ServiceNow to write back to Salesforce fields on its own, with no Salesforce trigger starting the chain, raise that on the demo call. Automation logic in the connector is built from the Salesforce side, and that detail is the one that most often surfaces after purchase with other products.

Making the Call on ServiceNow Integration with Salesforce

Two questions settle this. How many people working in Salesforce need ServiceNow data without holding a ServiceNow license? And how often will your field mapping change after go-live?

If the real answer to the second one is “often”, a custom build becomes a standing line on your engineering budget. Every mapping change is a deploy. Every ServiceNow release is a regression test nobody scheduled.

Whatever ends up on your shortlist, run it against a real workflow before the trial expires. Take your messiest Case type, the one sitting on a custom ServiceNow table, and push it through end to end.

Most integrations look fine on the third field and show their limits somewhere around the twentieth.

Get this right and the Slack message never gets sent. Your agent reads the incident status on the Case, tells the customer when the fix lands, and moves to the next ticket.

The questions below are the ones that come up before you get there.