ServiceNow Integration Interview Questions and Answers

Once the panel has finished with Business Rules and Client Scripts, they move to how your instance talks to everything outside it, and the questions get specific fast. Which direction was the call. Which authentication. What happened when the vendor endpoint went down. This post works through the integration questions from the RizeX Labs ServiceNow question bank, with the data import and inbound email questions that sit beside them, because Import Sets and inbound email actions are integrations too even when nobody calls them that.

Integration fundamentals

What is Integration in ServiceNow?

Integration is any exchange of data or actions between your instance and a system outside it. A monitoring tool raising incidents, an HR system pushing joiners into sys_user, a CMDB load from an asset inventory tool. All of it is integration.

State direction first, because everything else follows from it.

Inbound means the external system calls ServiceNow. ServiceNow is the server, and you expose something for them to call: the Table API, a Scripted REST API, a SOAP web service, an email address, or a data source that pulls a file.

Outbound means ServiceNow calls the external system. ServiceNow is the client. You build a REST Message, a SOAP Message or an IntegrationHub action, and something triggers it: a Business Rule, a Flow, a UI Action, a Scheduled Job.

This is the trainer's favourite trap. "Do you know integrations?" "Yes." "Where have you used it?" Silence. Knowing the word is not the answer. Naming the direction, the table, the trigger and the endpoint is the answer. Specificity creates credibility.

Types of integrations?

IntegrationHub lets Flow Designer call external systems without you scripting the REST Message by hand. A spoke is a packaged set of actions for one product, for example the Microsoft Teams spoke or the Active Directory spoke. You configure a connection and credential alias once, then drop the action into a flow.

Two things panels check. Most spokes need an IntegrationHub subscription, so a personal developer instance will not have the full set. And a spoke is still an HTTP call underneath, with the credentials and error handling already built.

What is LDAP Integration and its use?

LDAP integration pulls user and group data from a directory service, almost always Active Directory, into ServiceNow.

1. An LDAP Server record holds the host, port and the service account used to bind.
2. LDAP OU Definitions say which organisational units to read and which object class to read from each. Usually one for users, one for groups.
3. Each OU definition points at a data source, which lands rows in an Import Set staging table.
4. A Transform Map moves those rows into sys_user, sys_user_group or sys_user_grmember.
5. A Scheduled Import runs the load, normally nightly. An LDAP listener picks up changes closer to real time.

The use is threefold. User records arrive without anyone typing them, group membership drives assignment and roles, and authentication can point at the same directory so people log in with their corporate password.

Coalesce matters here more than anywhere. Match on something unique and stable, such as the AD object GUID. Coalesce on a display name and you create duplicate users the first time two people share a name.

What the interviewer is actually checking

• Whether you say "inbound" or "outbound" without being prompted.
• Whether you can name the table and the trigger, not only the protocol.
• Whether you know IntegrationHub is licensed separately and wraps HTTP.
• Whether you treat LDAP as an import pipeline rather than a sync button.

REST and SOAP

What is REST integration?

REST integration exchanges data over plain HTTP methods against a resource URL, usually with a JSON body.

Outbound you create a REST Message record (sys_rest_message) plus a method record carrying the endpoint, HTTP verb, headers and variable substitutions, then call it from server script with sn_ws.RESTMessageV2.

Inbound you either use the out of box Table API, which exposes every table at /api/now/table/<table_name> and respects ACLs, or build a Scripted REST API when you want your own resource path, request format and response body.

Authentication types worth listing:

Never hardcode credentials in script. Point the method at a credential record or authentication profile so the secret lives in one place and rotates in one place.

Here is an outbound call with the error handling a panel expects to see.

(function createVendorTicket(current) {

    var request, response, status, body, parsed;

    try {
        // 'Vendor Ticketing' = REST Message record, 'Create Ticket' = its POST method
        request = new sn_ws.RESTMessageV2('Vendor Ticketing', 'Create Ticket');

        // Credentials come from the auth profile on the method, not from here
        request.setRequestHeader('Content-Type', 'application/json');
        request.setStringParameterNoEscape('number', current.number.toString());
        request.setStringParameterNoEscape('summary', current.short_description.toString());
        request.setHttpTimeout(30000);

        response = request.execute();
        status = response.getStatusCode();
        body = response.getBody();

        if (status == 200 || status == 201) {
            parsed = JSON.parse(body);
            current.u_vendor_ref = parsed.ticket_id;
            current.update();
            return;
        }

        if (status >= 500 || status == 429) {
            // Transient. Worth another attempt later.
            gs.eventQueue('vendor.ticket.retry', current, status, body);
            return;
        }

        // 4xx other than 429 means our payload is wrong. Retrying will not help.
        gs.error('Vendor ticket rejected for ' + current.number + ', HTTP ' + status);

    } catch (ex) {
        // Timeout, DNS or network failure. execute() throws, it does not return.
        gs.error('Vendor call failed for ' + current.number + ': ' + ex.message);
        gs.eventQueue('vendor.ticket.retry', current, '0', ex.message);
    }

})(current);

Three points from that script that interviewers pick at.

Error handling. A call fails in two ways. The endpoint answers with a bad status code, which you read from getStatusCode(), or the call never completes and throws into the catch block. Handle both. response.haveError() and response.getErrorMessage() give the same information in another shape.

Retries. Do not retry inside the Business Rule. Raise an event or flag the record, and let a Scheduled Job pick up failures and try again with a growing gap between attempts. Retry only 5xx, HTTP 429 and connection failures. A 400 means your payload is wrong and a thousand retries will not fix it.

Where it runs. This is server side script. It cannot run from a Client Script, and if the endpoint sits inside a private network it needs setMIDServer(). Candidates know syntax and not execution. When it runs, where it runs, what data it can reach. That is the part panels probe.

What is SOAP integration?

SOAP integration exchanges XML envelopes over HTTP against a service described by a WSDL contract.

Outbound you create a SOAP Message record and import the WSDL. ServiceNow generates a function per operation with the envelope prefilled and the variables marked. You call it with sn_ws.SOAPMessageV2, which mirrors RESTMessageV2: set parameters, execute, read the status code and body, wrap it in try and catch.

Inbound ServiceNow publishes a SOAP endpoint per table at /<table_name>.do?WSDL, supporting insert, update, delete, get and getRecords. A Scripted SOAP Service covers contracts that do not match a table.

You meet SOAP mainly on older, heavily governed on premise systems. Nobody starts a new integration on SOAP in 2026, but plenty of running ones are still on it.

Difference between REST and SOAP?

MID Server and ECC Queue

What is MID Server?

MID stands for Management, Instrumentation and Discovery. It is a small Java application installed on a server inside the customer's own network.

It solves a firewall problem. ServiceNow runs in the cloud and cannot reach an on premise database, an internal API or a switch in a data centre, and opening an inbound hole in the corporate firewall is not acceptable. So the MID Server sits inside the network and makes outbound HTTPS calls to the instance asking whether there is work for it. The instance never initiates a connection inward.

What runs through it: Discovery probes and Service Mapping, IntegrationHub actions against internal systems, JDBC data sources, LDAP against a directory that is not internet facing, and any REST or SOAP Message where you call setMIDServer().

What is ECC Queue?

The External Communication Channel queue, table ecc_queue, is the message box between the instance and its MID Servers. Every record has a queue of output or input, plus an agent, topic, name, source and payload.

• Output records are instructions written by the instance. State moves to processed once the MID Server picks them up.
• Input records are results posted back by the MID Server. A sensor or business rule processes them and the state moves to processed or error.

The MID Server polls on a short interval, takes the output records addressed to it, does the work and writes an input record back. Nothing is pushed to it. ecc_queue is the first place you look when a Discovery run or a MID based integration produces nothing.

What the interviewer is actually checking

• Whether you name a real authentication type and say where the credential is stored.
• Whether you separate a bad status code from a thrown exception.
• Whether you know retries belong outside the transaction, and 4xx is not retried.
• Whether you understand the MID Server connects outward, not inward.
• Whether ecc_queue is the first table you name when a MID integration is silent.

Email and inbound actions

What is inbound email action?

An inbound email action is a record on sysevent_in_email_action that runs when an email arrives at the instance mailbox. It is how an email becomes or updates a record.

There are two types. A Record Action runs a script with an email object and a current record in scope, so you can create an incident from the body or update one from a reply. A Reply Email sends a response back to the sender.

Inside the script you have email.subject, email.body_text, email.origemail, email.body (parsed name colon value pairs), and current pointing at the target table set on the action.

How inbound email actions are triggered?

Learn this as a sequence, because "an email comes and it runs" is not an answer.

1. The email reading job connects to the mailbox over POP3 or IMAP, or the instance receives on SMTP.
2. Each message is written to sys_email with type received.
3. The instance classifies it as New, Reply or Forward. A watermark in the body, or a recognised record number in the subject, makes it a Reply against that record. A prefix such as "FW:" makes it a Forward. Anything else is New.
4. Inbound email actions on the target table are evaluated in order, lowest first, and only those whose type matches the classification are considered.
5. The condition on each action is checked. Matching actions run.
6. If an action has Stop processing ticked, no later action runs for that email.

Panels turn this into a debugging question. "Someone replied to a notification and the incident did not update. What do you check?" Look at sys_email for the received record and its state. Check whether the watermark survived, because many mail clients strip it. Then the classification, the order of the actions, whether an earlier one stopped processing, and the target table. Candidates who can only define an inbound email action lose this question to candidates who can trace one.

Difference between inbound and outbound email actions?

Strictly, "outbound email action" is loose wording for a Notification. If a panel uses the phrase, answer about Notifications and say so.

Data management and import

What is Import Set?

An Import Set is the staging mechanism for loading external data into ServiceNow.

A data source defines where the data comes from: a file upload, FTP or SFTP, a JDBC connection through a MID Server, an LDAP OU, or a REST payload. Loading it creates a staging table, usually prefixed u_imp_, holding every incoming row as text, plus an Import Set record (sys_import_set) and one Import Set Row per record.

Nothing has touched your real data yet. That is the point. The staging table is a safe place to see what actually arrived before any of it reaches incident or sys_user.

What is Transform Map?

A Transform Map defines how staging rows become target table records. It holds:

• The source table and target table.
• Field maps, one per column, saying which staging field feeds which target field. A field map can also be a script that computes the value.
• Transform scripts running at onStart, onBefore, onAfter, onComplete and onForeignInsert. source is the staging row, target is the record being written, and setting ignore to true in onBefore skips the row.
• Run order, when several maps run against the same import set.
• Run business rules, which decides whether Business Rules fire on the target record during the transform. Switching it off is faster, and is the usual reason a Business Rule does not run on imported records.

What is the coalesce field on Transform Map field maps and what is it used for?

Coalesce is a checkbox on a field map. It marks that field as the matching key for the transform.

For each row, the transform looks in the target table for a record whose coalesce field equals the incoming value.

• Match found, the existing record is updated.
• No match, a new record is inserted.

With no coalesce field on the map, every row inserts. Run the same file twice and you have two sets of records.

Tick coalesce on more than one field map and they combine with AND, so the transform looks for a record matching all of them. That is how you handle data with no single unique column, for example a CMDB relationship coalesced on both parent and child.

Choose the field on one rule: it must be unique and stable in the source system. Employee ID, AD object GUID, the vendor's own ticket ID. Not a person's name, not a field the source leaves blank. You can also coalesce on a scripted field map, returning the value to match on, which suits keys that need cleaning first.

What happens if coalesce field fails?

Two different failures, and interviewers want both.

The coalesce value is empty on the incoming row. There is nothing to match against, so nothing matches, so the transform inserts. Every later run inserts again. This is the standard cause of an import that keeps creating duplicates. The fix is to reject the row before it inserts, by setting ignore = true in an onBefore transform script when the key is blank, and logging the skip.

The coalesce field is not actually unique. Two source rows carry the same key, or the target table already holds several records with that value. The transform matches the first record it finds and updates it, so the second row overwrites the first and you lose data quietly. That is worse than duplicates, because nothing looks broken.

Where to look: the Import Set Rows list shows each row's status, and the transform history under System Import Sets shows inserts against updates per run. A run with a high insert count and no updates is almost always a coalesce field that arrived empty.

What the interviewer is actually checking

• Whether you treat the staging table as a safety layer, not an extra step.
• Whether you explain coalesce as insert against update, not only as matching.
• Whether you know multiple coalesce fields combine with AND.
• Whether you can name a real cause of duplicate records after an import.
• Whether you know "Run business rules" exists and what turning it off does.

Preparing for the integration round

Integration answers are judged on specifics. Anyone can say REST is lighter than SOAP. Far fewer can say which REST Message they built, what the endpoint returned on failure, how the retry worked and where the credentials sat. Take two integrations you have actually touched, including a practice one on a personal developer instance, and walk through each end to end: trigger, direction, authentication, payload, response handling, failure case.

If you want that practice with a trainer who asks the follow up questions a panel asks, the ServiceNow training programme at RizeX Labs builds integrations on a live instance rather than on slides.