Custom tables, Creator & app licensing.

How custom work is licensed.

ServiceNow licenses custom applications in one of two ways: through the Creator licence, which entitles a user to build and run applications on custom tables, or through an app-based subscription, which prices a defined custom application by its own metric. Admodum is an independent, buyer-side software licensing advisory firm; this page explains custom application licensing because it is where well-intentioned platform expansion most often outruns the entitlement that was budgeted.

A custom table is a data structure the customer creates rather than one supplied by a ServiceNow package. A Creator licence — sometimes referenced through App Engine entitlements — lets a user build and operate applications on those custom tables using the low-code tooling, without consuming a full functional-package licence. It is priced below the product packages described in the ITSM, ITOM, CSM and HRSD package tiers precisely because it does not include their out-of-the-box applications. The model rewards organisations that build genuinely new capability on their own tables, and charges more when a custom build leans on the data and logic of a package they have separately licensed.

When a custom app re-triggers package fees.

The central licensing question for any custom application is not how it was built but which tables it touches. A custom application built on custom tables under a Creator licence stays within that entitlement. The moment that application reads or writes to a licensed package's tables — the incident table, the case table, an HR table — the users operating it can be deemed to require that package's fulfilment-user licence.

This is the mechanism that turns a modest internal build into an unbudgeted line at the true-up. A team builds a custom approvals app to streamline a process; the app pulls a field from the incident table for context; and at reconciliation those users are counted against the ITSM package rather than the cheaper Creator entitlement. Nothing in the build felt like a licensing decision, yet the table interaction made one. The fulfilment-user definition that this turns on is set out in full at fulfilment, requester and approver users, and the true-up where it surfaces at usage analytics and the annual true-up.

The corollary is constructive: the same logic that creates the risk also defines the remedy. If a custom application can be designed to hold its own data on custom tables and to integrate with package data through controlled, well-understood interfaces rather than direct table access, it can often be kept within Creator scope. The design decision and the licensing decision are the same decision, which is why custom development on ServiceNow should never be treated as a purely technical matter handled downstream of procurement.

Creator versus app-based subscriptions.

Where the Creator licence covers a user's right to build and run custom applications broadly, an app-based subscription prices a single defined custom application by its own metric — often the number of users of that specific app. The two are not interchangeable, and the right choice depends on how many custom apps an organisation runs and how many people use each.

A broad internal development capability, with many small apps used by overlapping populations, usually favours per-user Creator entitlements that travel with the builder and user across apps. A single high-value custom application used by a large, well-defined population may be cheaper under an app-based subscription scoped to that one app. The error to avoid is defaulting to whichever the vendor proposes first; the buyer should model both shapes against the actual portfolio of custom apps and choose on cost, not on convenience. The wider model these choices sit within is mapped at the ServiceNow licensing model pillar, and the consumption-metered cousins of these entitlements at subscription units and consumption metrics.

The buyer-side table-to-licence map.

The practical control is a table-to-licence map. Inventory every custom application, list the tables each one reads and writes, and mark which of those tables belong to a licensed package and which are genuinely custom. The output shows, application by application, which builds are safely inside the Creator entitlement and which are pulling their users into a package fee.

That map does two jobs. Before a build programme, it lets architecture and procurement design new applications to stay within Creator scope, avoiding the fee before it is incurred. After the fact, it identifies the existing applications whose table interactions are inflating package counts, each of which is a candidate for redesign or for renegotiation at renewal. Either way the map converts a vague unease about custom development cost into a specific, defensible list of what to change and what to challenge, which is the same evidentiary discipline Admodum applies across the ServiceNow knowledge hub and the ServiceNow blog cluster.

One caution belongs here. A redesign that moves work off a package table is a licensing improvement only if it is genuine; re-pointing a field while leaving the underlying dependency in place will not survive scrutiny at an audit, and contrived workarounds can read as bad faith. The defensible position is real architectural separation, documented, where the custom application truly operates on custom data. The engagement that builds and defends that position opens at the ServiceNow practice or directly at contact.

A worked example of the trap.

Consider the most common pattern Admodum sees. An operations team, holding only Creator entitlements, builds a custom asset-tracking application on its own custom tables. Six months later, to enrich the records, a developer adds a lookup that reads the incident table so the app can display related outages. No new licence was bought, no procurement conversation took place, and the app works exactly as intended.

At the next reconciliation, those operations users are counted against the ITSM package, because their application now reads a licensed ITSM table. A build that was correctly scoped to the cheaper Creator entitlement has, through a single convenience feature, pulled its entire user population into a full package fee. The cost was not in the asset-tracking logic; it was in one line of table access added long after the licensing decision was thought to be settled.

The lesson is that the licensing boundary is live for the life of the application, not just at its design. Every enhancement that reaches into a new table is a potential licensing event, which is why the table-to-licence map must be maintained as the portfolio evolves rather than produced once and filed. A standing review of table access, run as part of change control, catches the convenience feature before it becomes a fee. This is the discipline the ServiceNow practice embeds, and it is far cheaper than discovering the consequence at a true-up.