Integration Hub, RPA, and transaction based licensing, where the meter counts machine activity, runs at three in the morning, and answers to nobody. 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 twenty two, and today the meter stops counting people. Everything we have done since module three has been about human beings. Who is a fulfiller, who is a requester, who opened the module, who works cases, how many employees do you actually have. And every one of those questions has something useful in common, which is that you can go and ask somebody. Transactions are different. A transaction meter counts machine activity. A scheduled job running at three in the morning consumes exactly the same as it did last night, it will consume the same tomorrow, and there is nobody to interview about it. Which means every technique this course has taught you for controlling a licence line stops working, and you need a different one. Three checks, homework, let's go.
Five objectives. First, name the five triggers, integration events, flow executions, mobile refresh, scheduled jobs, and report frequency, all of which consume transactions with no person present. Second, find your threshold, because the transaction cap sits inside the order document rather than in any marketing collateral, which is exactly where session four trained you to go looking. Third, read the consequence correctly, and this is the one people get wrong, because crossing the cap pushes the tier toward Enterprise, which makes it a repricing rather than an overage. Fourth, separate the two hubs, Integration Hub for systems that expose an interface and RPA for systems that do not, because they solve different problems and buying the wrong one is expensive in a very specific way. And fifth, govern a meter that has no owner, which turns out to need an inventory and a monthly number rather than an approval step.
Four framings. Eight thousand seven hundred and sixty, which is how many times an hourly scheduled job runs in a year. Nobody approved eight thousand seven hundred and sixty of anything. Somebody approved a job, and said hourly, and that was a completely sensible thing to say. In the order, which is where the transaction threshold lives, not the product page and not the deck and not anybody's memory of the negotiation. A tier move, which is what crossing that cap triggers, pushing you toward Enterprise, and that is a repricing of the whole line rather than a per unit overage. And no owner, which is who watches machine consumption in most estates, because every individual integration has a builder and the aggregate has nobody. The note underneath is the pattern for this whole course. Every consumption problem we have found was created by a reasonable decision that nobody counted. Transactions are the purest version of it, because there is not even a person to ask.
Guest analyst clip. I once spent an afternoon looking for the source of a consumption number that had roughly doubled, and the answer was a dashboard. Not a big integration, not a strategic automation programme. A dashboard, on a custom table, built for an operations team who wanted to see their queue in real time, displayed on a screen on the wall of a room that, by the time I found it, that team had moved out of eighteen months earlier. The screen was still on. The dashboard was still refreshing. It had been refreshing every thirty seconds, day and night, weekends included, for a year and a half, for an empty room. And the thing I want you to take from that is not that somebody was careless, because nobody was. The person who built it did good work. The team that moved offices had no idea a wall display had a licence consequence, and why would they. There was simply no point in the entire chain where a human being was asked whether that thing should still be running. That is what a machine meter is. It is a bill for decisions that were correct when they were made and that nobody has revisited since, and the only defence is an inventory with a review date, because there is nothing else in the system that will ever tell you.
A dashboard refreshing every thirty seconds for an empty room, for eighteen months. Hold that one, because it is the honest picture of this meter. Not waste through negligence, waste through the complete absence of anybody whose job it was to look. So let's be specific about what consumes.
Five triggers. Integration event volume, inbound webhook events from external systems, and notice the problem immediately, because the volume is set by the other system, which is very often not yours and not under your control at all. Flow Designer executions, each flow execution against a custom table, where a single new flow on a busy table can outweigh a whole year of user growth. Mobile app refresh, the refresh cycles on a custom application, which scale with devices and with the refresh interval and never with your licensed user count. Scheduled jobs, hourly or sub hourly against a custom table, counting cumulatively, forever, whether or not anybody reads the output. And report run frequency, real time dashboards on custom tables, which is the story you just heard. Now read that right hand column again as a set. Not one of those five grows because your business grew. They grow because somebody configured something sensible and then went home.
So here is what actually changes when the meter counts machines. There is no activity audit, and that matters enormously, because module three's entire method was measuring what people really do and reclassifying the ones who do very little. A scheduled job does exactly what it was told, every single time. There is nothing to reclassify. Growth is decoupled from headcount, so your seat count can be flat and your business flat and your transaction count still doubles, because automation is the point of the platform and you are presumably succeeding at it. Failure is expensive, because a broken integration that retries is still consuming, and your worst month is frequently the month something was wrong, which is a genuinely unfair way to be billed and is nevertheless how it works. Non production counts, because test harnesses run harder than users do and a load test is quite literally a machine designed to generate volume, and session twenty four takes that properly. And nobody feels it, because an over licensed person is visible in a list and an over consuming job is a line in a system log that nobody reads until a renewal quote arrives.
Knowledge check one. Your headcount is flat, your fulfiller count is flat, and your transaction consumption grew sixty percent this year. What is the most likely cause? A, a counting error, since nothing else grew. B, new automation, flows, scheduled jobs, and integrations added during the year. C, more users logging in more often. D, ServiceNow changed the definition of a transaction. Pause here, and ask what actually drives this meter.
The answer is B, new automation. Transaction consumption tracks automation and not people, so flat headcount sitting next to sixty percent growth is the expected shape rather than a contradiction, and if that feels wrong it is because eighteen sessions of this course have trained you to connect a licence line to a population. Answer C imports the seat instinct one more time and it genuinely does not apply here, because a user clicking more simply does not move this meter next to a job that runs every hour of every day. Answer A is worth ruling out and is rarely the answer. And answer D does happen, and it is checkable in exactly one place, the product use definitions inside your order document. But start with the automation inventory, because that is where the growth almost always is.
Now the two hubs, which get confused constantly. Integration Hub connects systems that expose an interface, through spokes. RPA drives systems that expose no interface, by operating the screen the way a person would. When is each right. Integration Hub, almost always, when the target has an API. RPA, only when there genuinely is no API and no prospect of one arriving. What do they cost you. Integration Hub costs transactions plus spoke availability, which is gated by your tier, so watch for the tier bought to obtain one premium spoke that nobody has actually scoped a use case for. RPA costs bots plus the transactions those bots generate when they run, so it is two meters, not one. And the failure modes. For Integration Hub, buying up a tier for a spoke nobody needed. For RPA, automating a bad process instead of fixing it, at licence cost, forever. Read the note. RPA is a workaround with a licence attached, and sometimes a completely correct one. The question before you buy bots is whether that target system will still have no interface in three years.
Knowledge check two. A team proposes RPA bots to automate data entry into a vendor system that is due to expose an API next year. What is the buyer response? A, approve it, automation saves manual effort either way. B, wait for the API, or scope the bots as a dated bridge with a retirement date in the plan. C, refuse, RPA is never the right answer. D, approve it and negotiate a discount on the bots. Pause here, and ask what the thing that never gets retired costs you.
The answer is B, a dated bridge. A bridge with a retirement date written into the plan is a completely legitimate answer, and a bridge without one becomes permanent, which is session twenty one's unowned application wearing a different costume. Answer A is precisely how a temporary workaround acquires a permanent licence line, and notice it is not a stupid position, it is just an incomplete one. Answer C is too strong, because there really are systems that will never expose an interface, often the oldest and most critical ones, and bots are the honest solution there. And answer D negotiates the price of something you may not need in fourteen months, which is the reflex this entire course keeps asking you to interrupt. Ask what it is first. Ask what it costs second.
Now the threshold, and this is the most important slide in the session. Above a defined threshold, the transaction count caps the tier and pushes you toward Enterprise. That is a different event, and a worse one, than paying for units above an allowance. Four cards. Where it lives, inside the order document in the product use definitions, and session four built the habit of reading exactly that. Why it is worse than overage, because an overage is a variable cost you can reduce next month by changing behaviour, and a tier move reprices the whole line and does not reverse when your consumption falls back. How it is found, at the renewal, by the account team, with the consumption record in front of them, and the useful fact there is that you have access to the same record and can read it first. And what it changes today, which is that if you are sitting at seventy percent of your threshold, that is a governance trigger now, not an agenda item for a meeting in eleven months. This is the same asymmetry as tier migration in session seven. Anything that resets your baseline upward deserves far more attention than anything that bills you monthly.
Guest analyst clip. There is a moment in renewal negotiations that I have come to recognise, and it is the moment the account team puts a consumption chart on the screen. It is always well made. It always shows a line going up and to the right, crossing a threshold, and it is always accurate, because it comes out of your own instance. And the room goes quiet, because nobody on the customer side has seen this chart before, and the natural response is to start explaining. We had a big project. There was a migration. That period was unusual. All of which may be true and none of which helps, because you are now arguing about the past with somebody who has the data and you do not. What I tell clients is very simple. That chart exists whether or not you look at it. The consumption record is in your instance, it is yours, and the only question is whether you read it in month three or whether you meet it across a table in month eleven. Those two situations produce completely different meetings. In the first one you arrive with a trend that is bending downward because you did something about it. In the second one you arrive with an explanation. And I have never once seen an explanation move a price.
The chart exists whether or not you look at it. I would put that next to session ten's baseline, because it is the same idea, which is that in this relationship the data is not secret, it is just unread on one side of the table. So, governance.
Five points on governance, and notice as we go that only one of them is a document. An automation inventory, every scheduled job, flow, and integration with its frequency and its owner, which is session thirteen's register extended to things that run rather than things that store. A monthly consumption number, one figure, trended, against the threshold, because a trend line answers the only question that matters, which is when do you cross. A frequency review, asking of every hourly job whether hourly is a requirement or a default, and I would guess half of them are a default, and moving those to daily costs you nothing operationally at all. A failure alert that is also a cost alert, because retry storms consume, and the team fixing the integration should know the outage had a bill attached to it. And then the fifth, deliberately, no approval gate. Do not put a licensing approval in front of building automation. That slows down the exact thing the platform exists to do, and it will be routed around within a quarter. Count it, own it, review the frequency. That is the control.
Knowledge check three. You are at seventy percent of your contractual transaction threshold, eleven months before renewal. What is the right move? A, nothing yet, you are still inside the threshold. B, review job frequency and integration volume now, while a reduction still changes the renewal position. C, tell ServiceNow immediately and ask for a higher threshold. D, raise it at the renewal meeting when you have the full year of data. Pause here, and ask when a consumption fact stops being fixable.
The answer is B, review it now. Eleven months is enough time for a frequency review to actually show up in the trend line you carry to the table, and a curve that is bending downward argues for you in a way that a complete year of rising data never will. Answer A treats a threshold as a wall you have not hit rather than a trajectory you are on. Answer C opens the conversation from the weakest position available, volunteering a problem before you have made any attempt to fix it, and you will get a higher threshold at a price. And answer D is the mistake session fifteen named precisely, because it converts a fixable operational fact into a fixed negotiating fact. The cost of the same finding rises the closer you get to a signature date, every time, in every product we have covered.
Four levers, ordered by return on effort, which is not the order most estates try them in. One, frequency. The cheapest reduction available to you, hourly to daily on jobs that never needed hourly, no operational change, no negotiation, no permission required. Two, retirement, automations serving processes that no longer exist, and every estate has them, running perfectly, forever, producing nothing at all. Three, design, which means batching where events are chatty and asking honestly whether a real time dashboard needs to be real time, and those are engineering choices with a price attached that the engineers have never been shown. Four, the threshold itself, negotiated with a trend line rather than a hope, and negotiated before you cross it, because after you cross it, it is a tier conversation and a much more expensive one. Notice that three of those four never involve ServiceNow at all.
Guest analyst clip. The frequency review is the most boring recommendation I make and it is the one with the best return, so let me defend it properly. When somebody builds a scheduled job, they choose a frequency, and there is almost never a requirement in front of them that says how often. So they pick something that feels responsive. Hourly feels responsive. Every fifteen minutes feels professional. And that choice takes about four seconds and then it runs for years. When I sit down with a team and go through their job list one line at a time and ask, what breaks if this runs daily instead of hourly, the answer for a large share of them is nothing. Nothing breaks. The data feeds a report somebody reads on Monday morning. And you have just cut that job's consumption by a factor of twenty four, with no negotiation, no vendor conversation, and no architectural change. What I would say to anybody running this exercise is do not delegate it to the person who built the jobs, because they will defend the frequency they chose, which is human. Do it with the person who consumes the output, and ask them how fresh the data actually needs to be. They will tell you the truth, because they have no stake in the answer.
Ask the person who consumes the output, not the person who built the job. That is a good general rule for this whole subject, actually. Session twenty three takes the other consumption meter, the assist pool, and asks the harder question. Not how to size it, which session eight covered, but how to govern it month by month once it is live and burning.
Three sentences. Transactions are consumed by integration events, flow executions, mobile refresh cycles, scheduled jobs, and report frequency, none of which grows because your business grew and none of which has a person standing in front of it. The threshold lives in the order document rather than in the marketing material, and crossing it pushes the tier toward Enterprise, which reprices the line permanently instead of billing you for a month. And the controls are an automation inventory, a monthly trended number, and a frequency review, where the cheapest reduction available is simply turning the hourly jobs that never needed to be hourly into daily ones.
Homework, about an hour, five items. Find your threshold, which means opening the order document and the product use definitions and writing down the transaction cap, and if nobody in your organisation can find it, that is finding number one and it is a significant one. Count the scheduled jobs, how many run hourly or more often and against which tables, then multiply by eight thousand seven hundred and sixty and look at that number honestly. List the integrations, every inbound webhook source with the system that controls the volume, and note specifically which of those systems is not yours. Ask about bots, and if you hold RPA, name each bot, the system it drives, and whether that system now has an interface, because some of them will by now. And plot the trend, twelve months of consumption against the threshold, and work out where the line crosses and whether that point falls before or after your renewal date.
Five guides. ServiceNow Creator licensing has the transaction cap triggers in written form, the tier consequence of crossing them, and the Platform against Creator split underneath, and it is the one to read first this week. App Engine licensing explained covers the custom application side of the same order form, including the integration staging tables that quietly draw on your table allowance. The ServiceNow products list for 2026 shows where Integration Hub and Automation Engine sit in the catalog and what each is actually sold to solve. Avoiding true up surprises covers how consumption gets found at renewal rather than volunteered, which is the clip you heard in written form. And the license rightsizing playbook has the measurement cadence that turns a consumption trend into a negotiating position instead of a discovery. Next time, governing the assist meter. See you there.