Who was free that week decides more of these than architecture does
The choice between a delivered connector and a script on ServiceNow is usually settled by availability rather than by any principle. The developer who can write a script in an afternoon is on the project. The person who would configure a flow and wire up a delivered action is on a different one. Six months later nobody remembers the decision was a staffing accident, and the estate carries it anyway.
A configured integration is readable by people who did not build it. An admin who joined last month can open the flow, see which action calls out, see which record it writes, and explain the whole thing in a stand-up without reading a line of code. It also shows up when somebody asks what this instance talks to, which matters the first time your security team asks that question and expects an answer the same day.
A script is faster to write for the person who can write it, and it handles the cases a delivered action does not. It also becomes a private dependency on that person staying employed. Both routes are legitimate, and if you want to be precise about the vocabulary, the difference between a connector and an integration is worth settling before the argument starts. The failure is choosing without ever saying out loud which one you picked and why.
Find out what you are entitled to before you design anything
Settle a commercial question before the design discussion. Connector-based integration on ServiceNow is frequently licensed separately from the applications you already run, and exactly what your subscription covers sits in your contract rather than in any architecture guidance. Check your entitlement. Your account team and your own paperwork are the only reliable answers here, and I would not design around an assumption about it.
The practical effect is blunt. A team without the entitlement will script, whatever good practice says, because the alternative involves a purchase order and a quarter of waiting that the programme plan does not have room for. A commercial constraint is shaping a technical decision, and that happens far more often than design documents admit.
Surface it rather than working around it quietly. If the pattern you want costs money the programme has not budgeted, write that in the design as the stated reason for the scripted approach. It gives whoever handles the renewal something concrete to argue with, and it stops the next architect assuming the script reflected somebody's preference.
An upgrade maintains the connector and hands you back the script
Delivered connectors are maintained by the vendor. When the platform moves, the action moves with it, and the work on your side is regression testing rather than rewriting. Custom code is yours forever. Every family upgrade, every skipped release, every method that quietly stopped being supported becomes your problem to find and somebody's afternoon to fix.
That cost is invisible on day one and obvious three upgrades in. The script that took two days to write has eaten a week of attention across two years, spread thinly enough that nobody added it up. Teams who keep an honest tally of upgrade remediation effort usually find custom integrations sitting near the top of it.
None of this makes scripting wrong. It makes scripting a thing you have to fund. If you are going to write code on the platform, write code other people can maintain, keep it inside a scoped application, and give it the same review you would give an application you sell.
The cheerful path is what gets written under time pressure
Delivered actions often arrive with error outputs, timeouts and retry behaviour already modelled, because the vendor had to design for customers who would call them badly. A script gets whatever the author had time for. Under a deadline that means the path where everything works, a try block if you are lucky, and a log line that says the word failed and nothing else.
Visibility splits along the same line. A configured integration usually turns up in platform level logging where an operations person can find it without knowing in advance that it exists. A script logs wherever its author chose. That might be the system log, it might be a custom table nobody reads, it might be nowhere at all. The first outage is when you find out which.
Ask the question early rather than after the first missed batch. Decide what happens on a timeout, on a partial result and on a business rejection, then make sure errors reach a person who can act on them. A delivered action gives you a head start on that work. It does not finish it for you.
A credential sitting in a script is an incident waiting for a review
Scripts collect the worst credential habits on any platform, and ServiceNow gives them plenty of room. A password pasted into a script include during testing and never taken out. A token written into the code because the connection record was not ready on the day. An account with far more access than the integration needs, created once in a hurry and never looked at again.
Configured integration pushes you towards the credential and connection records the platform already keeps, with the access controls that come with them. That is no guarantee of anything. A connection alias pointed at an over privileged account is the same exposure with tidier paperwork. What changes is that you can find it without reading every script on the instance.
Give integration accounts the same handling you give human ones, with a named owner, a rotation schedule and a record of what they can reach. Getting service account identity right is dull work that pays out during an audit, and it is one of the few places where the configured route genuinely costs less over the life of the integration.
Pick the default and make the exception write itself down
Most real estates contain both kinds and will keep containing both. The useful discipline is deciding which one is the default and requiring a reason to deviate from it. State that the delivered connector wins where one exists and the entitlement allows it, and that anything else needs a written reason before it ships.
Record the exception instead of re-arguing it every quarter. Two sentences in the design note covering why the delivered action could not do the job, who owns the resulting code and what breaks when that person leaves. Nobody enjoys writing those two sentences. They take four minutes and they save a meeting every time somebody reopens the question.
The common failure is losing track of what exists rather than choosing wrongly. An estate with forty integrations and no list of them has a problem no design standard will fix. Putting an integration map before the roadmap gives the rest of this somewhere to live, and it turns a standing argument into a maintained document.
Open one integration this week and read the top of it
Pick the integration your service desk complains about most and answer three questions about it before Friday. Whether it is configured or scripted. Where it writes its errors. Which account it authenticates with, and who owns that account today.
If the third question takes you more than ten minutes, you have found the piece of work. If the answer turns out to be an account somebody created years ago with the password living in a script include, you have found something more urgent than whatever roadmap item you were planning to raise at the next architecture review.
Then check what the platform can already do for that one integration and what your subscription actually includes. If a delivered action covers the case and you hold the entitlement, replacing the script is a contained job with a payoff you will feel at the next upgrade. If neither holds, write down the owner today, because the person who knows how that script works will not always be a message away.
