Will ServiceNow charge per custom table/column?

Note: This article has been updated on 8/7/19, 4/19/22, and 9/29/22. Please see the updates at the bottom of the article for a splash of hope which is then quickly snatched away. ??

Dear ServiceNow,

We are your customers, users, developers, and administrators. We want real answers about your new?licensing model which seems to involve (at least potentially) charging your customers per custom table, and per custom field.

Let me start with a bit of a cautionary tale --

I once worked for a particular company in Portland Oregon. Let's call them Epoch. Without going into too much detail - Epoch had a database (not ServiceNow) with a single table that stored huge amount of data for each of their clients.

The problem was, each client had at least a few unique data points that this company needed to store. Epoch used a single table to store all of this, just adding columns for each unique datapoint that they needed to store (rather than using related tables to store some of this "situational" data, only situationally). After a couple years of this, they sort of just ran out of columns. With over a thousand columns in a single table, SQL Server would not allow them to create any new ones.

At this point, a reasonable company might step back and realize what a mess they've made of things, and try to split this data out into a bunch of separate tables. The queries and logic for this would be a little bit cumbersome, but probably shouldn't take a skilled developer more than a couple of days to get at least a basic proof of concept sorted out.

"Epoch" was not a reasonable company. What they did instead, was to re-use existing fields. They used a random existing field (let's say this field was "address_type") as a sort of pivot-point. If the address_type field contained the letter a, then every column was, you know, what it was. It was itself, as-labeled. If, however, address_type was b (or c, or d, etc.), then every single column represented a completely different datapoint. The name field for example, might hold some arbitrary data about the client's account, if the address_type field was b.

This resulted in a multitude of massive "joins", joining this table to itself over and over again, with increasingly complex queries and join statements as new clients were onboarded, and new "custom fields" were added (which actually meant new ways to re-use existing fields with new address_type values).

This was a thing that grew over the course of years, and the only person who had any idea what each field corresponded to, was the guy who built it. He wrote down several incomplete versions of the "mapping", each in scribbled handwriting, each consisting of about a quarter of the mappings we needed with some overlap, and each disagreeing with the others.

This guy - the one responsible for this mess, and the only one who had any idea how it worked - was the guy I was hired to replace, and by the time I joined, he was already one week into his two-weeks notice, and had mentally checked out.

---

The reason I mention that horror-story, is because that seems to me, to be exactly the kind of terrible database design that you, ServiceNow, seem to be encouraging with your new licensing model. Or at least, that is my concern, and that of the clients and other developers who I've talked about this with.

Now, maybe you're likely to say that creating new custom tables and columns is something you want to discourage. After all, you've got to store those tables and columns, right? - But that logic would be extremely short-sighted.

I could maybe even understand wanting to charge customers on a per-million-records basis; or maybe per-custom-column-per-million-records. Each additional datapoint for each additional record, at least has some direct relationship to the cost of storage. Even if that cost is the sheerest fraction of a fraction of a cent, you could point to an actual (extremely miniscule) amount that it costs for the database server storage capacity and resources.

But per column? - Per table? Regardless of how many records are in those tables, and how much data is in those columns?

Charging for these things doesn't make sense to me, and strikes me (and nearly everyone I spoke with) as "nickel-and-diming" your customers - unless you want to specifically discourage your customers from customizing their instance. But even if that were your goal, all that it would end up doing, is forcing customers to figure out unique-but-inefficient "tricks" for avoiding creating new custom tables and columns, just like what "Epoch" did in the story above.

If I can make a custom "config" table with 5 custom columns to store maybe 50 total records in some hypothetical application, it might save me from having to make and populate a custom field on every single one of, let's say, 2 million CIs. Just as a hypothetical example.

The inefficient "Epoch" method would save the customer money, but it would cost ServiceNow in terms of resources. The "config table" method however, would be much more effective and efficient for the customer, and for ServiceNow. Yet, based on my understanding of the licensing model, the more-efficient-for-everyone model is the one that would actually cost more money. Is that really the one that we want less of?

So, because nobody I've spoken with really seems to understand how the ServiceNow licensing scheme impacts them, or what the future holds from a licensing perspective, I've got a few questions for you, ServiceNow:

• What are your plans for your licensing model for the future?
• What are your goals with this licensing model?
• Are you trying to discourage "non-store" customization altogether?
• Can customers expect more opaque and confusing licensing changes in the future?

And here are some questions that members of the unofficial ServiceNow Discord Community have asked:

• Will we be charged for custom tables/columns in store apps? What about in apps/tools downloaded from the Share site?
• Does this licensing scheme replace other licensing schemes, or is it simply added on to the licensing model and fees we're already paying?
• What about customers who have spent years carefully architecting functionality to not result in unnecessary licensing costs? - Even if those existing tables/fields are "grandfathered in", we may already be locked into an architectural path that will cost us more money to further build onto, or require a lot of a re-architecture.
• Will customers have the ability to opt into the "old" licensing model? Do we have any say, when new licensing schemes are introduced?
• Why does it seem like our account representative(s) aren't trained/able to give a straight/clear answer about licensing? This is becoming more and more of a barrier to everything we want to do, and we should be able to get a meaningful, accurate answer, quickly.

Note: ServiceNow was given an opportunity to respond to these questions and comment on this article, prior to publishing. They did not respond to requests for comment in a timely manner.

What is the community saying?

From reading various threads and topics in the ServiceNow developer community Slack and Discord, this is not a topic on which there seems to be much division. From my interactions, most people seem to be on the same side of this discussion, which is to say that they're confused and annoyed; not just by the licensing model itself, but by why ServiceNow would take this approach (for all the reasons mentioned above, and more).

Here are some things that the community is saying about it:

"Every sales person I've talked to has a different idea of what the costs of the licensing are and how?they are coming up with the number. There's no consistency."

"I highly recommend everyone who cares about the pricing to have the rep write down how they calculate the cost."

"We tried that and the dude could not do it."

"Should it be that hard though? We don't have these issues with salesforce or the other erp's we use"

"When I started it was $X/itil user/mo. And then disco was [x/discovered] server/mo. That was it. Now there’s like 8 things like that. Not to mention some paying for approvers. Some paying for unrolled users if the # is more than 1/4 rolled to unrolled users."

"You know people are considering only inbound rest calls to avoid the new per-tx cost model."

Update 8/7/19

(See update from 4/19/22 below as well)

While I never heard back from ServiceNow's press contact, I was eventually able to get on the phone with ServiceNow's VP, Head of Product, Platform Business, Marcus Torres, who very graciously spent way more time than we had originally scheduled on the call with me to help me get some answers about the updated licensing model.

Here are a few points as I understood them, based on our call.

Note: Although SN was given the opportunity to respond to the below update, all of the points below are based on MY understanding from the conversation we had. They are not official statements from ServiceNow. ServiceNow has been, for some reason, extremely hesitant to discuss this topic officially or make any official statements about the direction of the platform's licensing model. Every ServiceNow customer has a unique license. I am not affiliated with, and do not represent ServiceNow. D'uh.

These are the claims made on the call:

1. The primary licensing metric is still user-based, not table or column-based.
2. The vast majority of ServiceNow customers should not notice any difference in how their licensing works, due to table/column limits of any kind.
3. ServiceNow looked at how existing customers are using custom tables and columns, and have tried to make sure that there is effectively zero difference in licensing, unless you reach an unusually large number of, for example, custom columns in a given table. My understanding is that only an extreme minority of their customers even would have been impacted by this licensing model if it were retroactive (which it is not).
4. ServiceNow say that they have done this "not as a source of revenue", but in order to encourage best-practice architecture, and thoughtful database design. (We now know that this and much of the rest of these points seem to have been a lie -- see the update from 4/19/22 below for more.)
5. Any existing custom tables and columns will be "grandfathered in". You will not be charged for them, or for tables/columns installed with Store apps.
6. Your "allotment" of custom database columns (which ServiceNow determined by looking at usage data for their existing customers, though Marcus refused to give me a specific number) counts upward from where you start when your new license takes effect, not from the OOB configuration. So if you plan to make a table with 12,000 columns, do it now! (Just kidding, please don't do that).
7. Basically, don't worry. You're almost certainly fine. (Edit: LOL this turned out to DEFINITELY not be true...)

I wrote this original article because I was approached by clients and other developers who wanted answers, and neither they nor I were able to get them. I have some points that I'd still like to clarify, but I now feel like I've got a good sense of most of the answers to the questions and concerns, and I am not worried about the changes to their licensing stifling best-practice development, or nickel-and-diming my clients. (Edit: Again, big ol' LOL on this one.)

Thanks for taking the time to chat, Marcus.

Update 4/19/22 (The Angry Rant)

It appears to me that, as far as I can tell, I was lied to. Most of the stuff claimed in the discussion with ServiceNow that went into the update on 8/7/19 seems to have been, at least to me, a lie.

(I'm using uncharacteristically hedgey language here, because SN has proven to be extremely litigious, but I want to make it clear that this is (a) based on what I was told, not on official statements; (b) my opinion, and (c) still not affiliated with or endorsed by ServiceNow).

After some discussions on the unofficial ServiceNow Community Discord, I've learned that ServiceNow has apparently been telling its customers that they'll be charged additional licensing fees after only TEN CUSTOM TABLES; Just as I predicted in this article, back in July 2019.

ServiceNow is now apparently charging not only per-table, but also nowadays, per HTTP transaction, and - I'm told - even per-megabyte for certain things! With all of these new and frankly absurd nickel-and-dime fees, have they reduced the base licensing costs to make up for it, so you have more of a "pay for what you use" model? Absolutely not, at least as far as I can tell.

So, to quote a YouTube video I made over a decade ago, "don't trust giant corporations - especially ones that don't give a [hoot] about you".

Update 9/29/22 (The Resigned Rant)

I don't even know what to say anymore. I certainly can't say that I didn't see something like this coming, but despite having very low expectations... I am still disappointed.

I've been told by a ServiceNow representative that despite ServiceNow's own documentation saying that "custom tables" that come within free ServiceNow Store applications of the type "Integration" will not count toward your severely-limited custom table count... that is not (or will soon not be) true.

Not only that, but I've been told (as have several others in the community) that the "cost-per-http-transaction" model that ServiceNow adopted really fairly recently - the one that used to give you "a million free transactions" (limited though that is in real-life) - is having its "free" transaction count cut at least in half. I've been told it'll be cut to either 500k, or possibly as low as 300k transactions(?). This is apparently despite the fact that the documentation, again, still says otherwise.

ServiceNow is going all-out in the wrong direction.

They could've built the now-deprecated Express as a locked-down version of Enterprise, with an easy and pre-built maint script upgrade-path to "unlock" an instance with a license upgrade. They could've got their hooks into the small-and-medium-business market, adding another revenue stream while also building "stickiness" as a company is growing, increasing their total market-share long-term, while also making SN affordable at all levels of business.

Instead, it feels exactly like when an old videogame is bought out by another company, who then adds a bunch of predatory microtransactions, makes the game completely pay-to-win, fires the entire dev team and screws off to collect the checks until it's no longer profitable to keep the servers alive, then kills it.

I hope that that isn't what's happening here. But as you can probably tell from the trajectory of the updates to this article over the last 3 years... hope is not something that I have a lot of left in my tank, when it comes to ServiceNow's pricing models.