The allowance nobody reads, the three user types, and the boundary a custom app crosses without anyone deciding. Three knowledge checks along the way, and 3 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 3 times in the session the frame splits and a senior licensing analyst gives the view from inside real ServiceNow negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session thirteen. Last two sessions were about people, the fulfiller line and the audit that fixes it. Today we move to the second counter in this module, and it is a stranger one, because it is not about people at all. It is about what your teams build. Custom tables, App Engine, and the boundary a custom application crosses without anybody deciding to cross it. And I want to give you the shape of the problem in one sentence before we start. An architect draws a table on a Tuesday afternoon, doing good work, solving a real problem, and your licensing position changes. Nothing in that moment tells anyone a price has moved. There is no warning, no approval step, no line item. Which is precisely why this counter surprises people at renewals, and why it sits in the same module as the fulfiller problem, because structurally it is the same failure. Three checks, homework, and by the end you will know where your own boundary sits. Let's go.
Five objectives. First, say what App Engine licenses, custom build on the Now Platform, and just as importantly what it does not license and never will, because the confusion between those two is where the money goes. Second, name the three surfaces, the tier, the user types, and the custom table allowance, which are the three things your order form sets and which are all negotiable, including the one nobody reads. Third, type the population honestly, Creator, Builder, and User, and understand why almost everybody belongs in the cheapest of those three. Fourth, find the boundary, the point where a custom application stops being App Engine and starts needing process licensing, whatever the application happens to be called. And fifth, govern the allowance, tracking tables against what you contracted so that a build decision never becomes a licensing surprise at a review. That last word, surprise, is the theme of this session and the next one.
Four numbers. Six in ten, estates that bought App Engine Plus for workloads Standard would carry, and that is the single biggest lever in this whole area. Thirty to fifty percent, the Plus premium over Standard for the same user counts, so in most of those estates that premium was paid for capability nobody exercised. Fifteen to forty percent, custom table growth across a single term, as teams shipped unmanaged applications against a fixed contract allowance, and notice the tension in that sentence, growing count, fixed allowance, which converge on a date. And twenty to thirty five percent, what estates overpaid by licensing heavy populations as Creators instead of Users, which is the second leak and it is the fulfiller problem wearing different clothes. Now the note underneath, because it changes how you prepare. ServiceNow does not publish App Engine pricing. Every deal is quoted. So there is no list price to argue against, no public benchmark, which means your own counts, your own table numbers and your own user typing, are the only benchmark you fully control. Let's hear how that plays out.
Guest analyst clip. App Engine is the area where I most often find customers who genuinely do not know what they have bought, and I want to be clear that this is not carelessness. It is structural. Think about who is involved in an App Engine decision. The platform team wants to enable citizen development, which is a good instinct. The business wants applications built quickly, also good. Procurement negotiated a line on an order form two years ago that says a tier, some user counts, and a table allowance. And those three groups never meet again. So the building happens, enthusiastically, and the allowance sits in a document nobody has opened since signature. I ran a review last year where the customer had shipped over forty custom applications in three years. Genuinely impressive work, real value, the platform team should have been proud. And they had never once counted the tables those applications created against the number on their order form. When we counted, they were substantially over, and the conversation that followed was not a negotiation, it was a purchase at whatever price was offered, because they had no position. The lesson is not build less. It is count while you build, because the counting is free at the time and expensive at the review.
Count while you build. And notice the structural point in there, three groups make this decision and they never meet again, the platform team enabling, the business consuming, and procurement holding a document from two years ago. That is not a failure of any one of them, it is a gap between them, which is exactly what the governance at the end of this session is designed to close. Now, what App Engine actually is.
What App Engine is, and what it is not, four rows. What it covers, custom build on the Now Platform, the workflow applications, forms, tables, and automations your teams create. What it is not, ITSM, HRSD, CSM, the process products, licensed separately on their own units. Who it is for, your developers and citizen builders plus the people who use what they built, as opposed to the fulfillers working incidents and cases in the shipped products. The unit, per user per year by user type, plus a custom table allowance, against fulfillers, subscribers, and product specific metrics on the other side. And the crossing point, which is the row that matters most. An application that stands alone on its own data stays in App Engine. An application that reads or writes ITSM, HRSD, or CSM data has crossed, whatever it is called. Now sit with the note underneath. The boundary matters because the platform makes crossing it easy. A custom application that assigns incidents has left App Engine territory and entered process product licensing, and nothing in the build experience tells you that. No warning dialog. No approval. Just a field reference that seemed obviously useful.
Three things your order form names, and all three are negotiable. The tier, Standard or Plus, which sets feature depth and the process scope of what you may build, and remember six estates in ten bought Plus for workloads Standard carries at a thirty to fifty percent premium. When you next look at that line, the question to ask internally is simple, which Plus feature are we actually using, and if nobody can name one, you have found your first lever. The user counts by type, Creator, Builder, User, which is the second largest lever and where the honest mix is usually far cheaper than the quoted one. The custom table allowance, how many tables your applications may create before the price shape changes, and I will say this plainly, almost nobody reads this line, which is why it moves quietly. And underneath all three, the uplift, a seven percent default annual increase, negotiable to three or four, compounding on whichever number you accept, so session four's cap applies here as much as anywhere. And the closing point, nothing is published, App Engine is quoted deal by deal, so you either bring your own counts or you negotiate blind. There is no third option.
Knowledge check one. Your teams build a standalone equipment booking application on its own tables, touching no ITSM data at all. What licenses it? A, ITSM, because it runs on the same platform. B, App Engine, within your custom table allowance. C, nothing, because custom apps are included in the platform. Or D, App Engine Plus, because it is a production application. Pause here, and ask what the application actually touches.
The answer is B, App Engine, within your allowance. A standalone application on its own data is precisely what App Engine covers, and the tables it creates draw against the allowance you contracted. Answer A confuses the platform with the process products, and running on the Now Platform does not make something ITSM any more than running on Windows makes something Microsoft Office. Answer C is the belief that produces the fifteen to forty percent table growth, because if building feels free then nobody counts, and I hear this one from technically excellent people. And answer D assumes production means Plus, which is exactly the tier error six estates in ten make. Standard carries plenty of production workloads. Production is not a tier test, capability is.
The three user types, and you will recognise the shape of this immediately. Creator, full development, building applications, defining data models, writing the hard parts, and who belongs is a small fraction of the population, named individuals. The leak is whole teams licensed here because they touch a development instance, and touching a dev instance is not the same as building applications. Builder, citizen development, configuring, assembling, extending within guardrails, and who belongs is the power users who genuinely build low code applications. The leak here is subtler, it is reasonable in principle and oversized in practice. And User, consume the applications, open them, use them, get work done, and who belongs is almost everybody, because this is the cheap tier and the honest home of most people. The leak, undersized, because typing defaults upward. Now the note, and it will sound familiar. Estates that licensed heavy populations as Creators paid twenty to thirty five percent more than the honest mix, and the typing question is the same behavioral test as the fulfiller line. What does this person actually do. Build, configure, or consume. Three behaviours, three prices.
Knowledge check two, and it is arithmetic on that test. Your quote types three hundred people as Creators. You investigate and find that twelve of them build applications, forty configure within guardrails, and two hundred forty eight simply open the applications and use them. What is the honest mix? A, three hundred Creators, they all have access to the applications. B, twelve Creators, forty Builders, two hundred forty eight Users. C, fifty two Creators and two hundred forty eight Users, because builders are creators. Or D, three hundred Users, since only the applications matter. Pause and apply the behavioral test.
The answer is B, and it maps cleanly, twelve build, forty configure, two hundred forty eight consume. Three behaviours, three types, no interpretation required once you have the activity. Answer A is the quoted default and the reason estates overpay twenty to thirty five percent, and notice the justification embedded in it, they all have access. Access is not a licensing test, any more than seniority was in session eleven. Answer C is more interesting, collapsing the middle tier and paying Creator rates for citizen development, which defeats the purpose of the Builder type existing at all, and I see this where somebody decides the three types are too fiddly to administer. And answer D undertypes the fifty two who genuinely build, which is not a saving, that is an exposure, and undertyping is how you turn a cost conversation into a compliance conversation. Type honestly in both directions.
Two boundary rules that decide most disputes. Rule one, process data crosses the line. An application that reads or writes ITSM, HRSD, or CSM data needs process aware licensing on top of App Engine. What the application is called is irrelevant, what it touches decides, and I want to stress reads, not just writes. Rule two, scoping decides the table. Custom tables built outside properly scoped applications can trigger separate charges, and the same table built inside a scoped application may sit comfortably inside your allowance. Same table, different treatment, based on how it was built. Why does this happen? Because the platform makes crossing trivial. Pulling an incident reference into a custom application is a five minute job that nobody experiences as a purchasing decision. And the control is equally simple, a licensing question in the build review. What data does this application touch, is it properly scoped, and how many tables does it add. Three questions, asked before code. And the note ties it back, this is the accidental fulfiller from session eleven in a different costume, an operational decision with an invisible price tag, made by a competent person following good practice.
Guest analyst clip. The boundary rule about process data is the one I have to explain most often, and the reaction is always the same. Somebody says, but we are only reading a field. And I understand the instinct, reading feels passive, harmless, surely you cannot be charged for looking. But think about it from the vendor's side for a moment, because their logic is not unreasonable. They sold you a process product with its own data model, its own workflows, years of engineering in how incidents are structured. If your custom application can surface and use that, it is deriving value from the process product, whether it writes back or not. Now, I am not telling you to accept every boundary claim you receive, because the specifics matter enormously and I have argued plenty of them down. What I am telling you is not to be surprised by the principle, because buyers who are surprised by the principle end up conceding the specifics too. The practical advice I give is this. When a team wants to build something that touches process data, do not say no. Ask whether they need the live data or whether they need a copy, a summary, or a link. About half the time the requirement is genuinely satisfied by something that does not cross the line, and that is a design conversation, worth having on a whiteboard rather than in a renewal.
Do they need the live data, or a copy, a summary, or a link. That question, asked at design time, is worth real money, and about half the time the answer removes the crossing entirely. And the meta point matters too, do not be surprised by the principle, because a buyer who is surprised by the principle tends to concede the specifics as well. Understand why the rule exists and you can argue about where it applies. Now, the allowance itself.
The line in your order form nobody reads, five steps. Find it, every order form carries a custom table allowance, so locate the number and the definition of what counts toward it before you need them, which is a fifteen minute job today and a crisis later. Count against it, current table count versus allowance, refreshed quarterly beside the other counters from session five, and remember why this one bites, low visibility, high true up risk. Watch the trend, because tables grew fifteen to forty percent across a single term in the estates we reviewed, and a flat allowance against a growing count converges on a date you can actually predict, which turns a surprise into a plan. Negotiate headroom, since the allowance is a negotiation surface like any other and headroom bought at signature is cheaper than tables discovered at a review. And retire what died, because applications built for projects that ended still hold their tables, and decommissioning is the cheapest capacity you will ever recover, it costs nothing but attention. Final check.
Knowledge check three. A custom application your team built now pulls incident records to display them alongside its own data. Display only, no writing back. What changed, licensing wise? A, nothing, it only reads, it does not write. B, it crossed into process licensing, because it touches ITSM data. C, it needs an extra custom table allowance only. Or D, it needs Plus rather than Standard. Pause, and ask which rule governs, what it is called or what it touches.
The answer is B, it crossed. The rule is reads or writes, so answer A's read only distinction does not save you, and this is the single most common surprise in App Engine estates, exactly as the clip described. The application has entered process product licensing whatever it is named and however small the integration felt at the time. Answer C addresses the table count, which is a different meter entirely, and answer D changes tier without addressing the crossing at all, so you would pay more and still be exposed. Now here is the practical response, and it is not panic. Decide deliberately whether the application needs that data. Sometimes it genuinely does, and then you license it properly and you have made a real decision with your eyes open. And sometimes, as we heard, a copy or a summary or a link would serve perfectly well, and the crossing disappears. What you must not do is discover the answer at a review.
Four controls that keep the build honest, and every one mirrors the role controls from session twelve because the failure mode is identical. A licensing question in the build review, what data does it touch, is it scoped, how many tables, three questions on the design template answered before anybody writes code, and note where I am putting it, in the design template, not in a separate governance process nobody attends. A table register, every custom table with its application, its owner, and whether the application is live, which is session three's product inventory at table resolution. Typing on evidence, Creator, Builder, and User assigned from what people actually do rather than from what they were quoted, reviewed with the quarterly pass rather than at purchase. And a decommission path, so that when an application retires its tables go too, because without that the count only ever rises and your allowance is finite. Four controls, none of them heavy, and together they mean nobody is ever surprised. One more clip before we close.
Guest analyst clip. I want to make the case for the table register, because it is the control people resist most and it is the cheapest one on the list. The resistance is always the same. We are trying to enable rapid development, and you want us to fill in a form. And I have sympathy with that, genuinely, because heavyweight governance kills the thing that makes this platform valuable. So let me describe what I actually mean. Three columns. Table name, which application it belongs to, and who owns that application. That is it. It takes about thirty seconds per table, and it can be generated automatically from the platform for the tables that already exist. What it buys you is disproportionate. First, you can count against your allowance at any moment, which means the renewal conversation is arithmetic rather than archaeology. Second, and this is the part people do not anticipate, when an application is retired you can actually find its tables. Without the register nobody knows which tables belonged to the thing you just switched off, so they stay forever, consuming allowance for an application that no longer exists. I have seen estates where a third of the custom tables belonged to applications nobody could identify. That is not a licensing problem at that point, it is an archaeology problem, and archaeology is expensive.
A third of custom tables belonging to applications nobody could identify. And the framing there is right, three columns, thirty seconds, mostly auto generated. If your governance proposal is heavier than that, it will be resisted and it will deserve to be. Light enough to survive contact with a delivery team is a design requirement, not a compromise. Let's recap.
The build, in three sentences. App Engine licenses custom build on three negotiable surfaces, the tier, the user types, and the custom table allowance, and none of it is published, every deal is quoted, so your own counts are the only benchmark you control. The typing question is the fulfiller question again, Creator, Builder, and User map onto build, configure, and consume, and estates that typed heavy populations as Creators paid twenty to thirty five percent more than the honest mix. And two boundary rules decide the disputes, an application that reads or writes process data has crossed into process licensing whatever it is called, and tables built outside properly scoped applications can be charged separately. Next session we take every counter in this module, users, tables, integrations, and show what happens when nobody tracks them. The true up. How quiet growth becomes a bill, what ServiceNow actually measures, and the paper that governs the conversation when it arrives.
Homework, about an hour. One, find the allowance, locate the custom table allowance on your order form and write the number down, and if you genuinely cannot find it, that absence is this week's finding and it is worth escalating. Two, count your tables, current custom table count against that allowance, plus the count from a year ago if you can get it, because the trend matters more than the number. Three, type your App Engine users, how many genuinely build, how many configure, how many just consume, compared against how they are licensed today. Four, test one application, take your most business critical custom app and ask whether it reads or writes ITSM, HRSD, or CSM data, and note the answer honestly. And five, check the tier, Standard or Plus, and which Plus features your teams actually use, and I will make a prediction based on six estates in ten, if you are on Plus, nobody will be able to name one.
Further reading, five guides. The App Engine explainer is today's session in written form, the three surfaces, the user types, the boundary rules, and the benchmark data behind every number I quoted. The products list shows where creator and platform sit in the wider catalog and how App Engine relates to the process products it must not quietly become. The true up surprises guide covers how custom tables consume entitlement buyers did not know was metered, and it is direct preparation for next session. The rightsizing playbook applies the rightsizing method to platform lines as well as user lines, including unused scopes and retired applications. And the audit pillar shows where custom table findings sit in the wider review landscape. That is session thirteen. Find your allowance, count your tables, and I will see you in session fourteen for the true up.