In ServiceNow, the paid licence attaches to the fulfilment user who works a request, not the requester who raises it or the approver who signs it off. The Admodum read on the distinction that decides the majority of platform cost — and where the line is policed at audit.
In ServiceNow, the paid licence attaches to the fulfilment user who works a request, not to the requester who raises it or the approver who signs it off. Admodum is an independent, buyer-side software licensing advisory firm; this page sets out exactly where the boundary sits, because it decides 60 to 80 per cent of the platform bill.
A fulfilment user is a named, licensed user who creates, updates, assigns and resolves records inside a licensed application — the IT agent closing incidents, the customer-service agent working cases, the HR specialist actioning requests. A requester is an end user who raises a request, reports an incident or browses the service catalogue through the self-service portal. An approver is a user who only approves or rejects requests routed to them. Only the first needs a paid licence. This page is a spoke of the ServiceNow licensing model pillar.
The ServiceNow model is built so that the large population who raise and approve work do not carry a paid seat. An organisation of 40,000 employees might have 38,000 requesters and 2,000 fulfilment users. The cost attaches to the 2,000 who fulfil, not the 38,000 who request.
This is the single most consequential fact for cost control, and the most commonly misread. Procurement teams new to ServiceNow often assume that everyone who touches the platform needs a licence and budget accordingly, which over-states cost dramatically. Conversely, IT teams provisioning the platform sometimes hand out agent roles liberally, which quietly converts unpaid requesters into paid fulfilment users. The discipline is to keep casual and self-service users firmly on the requester tier and to reserve fulfilment roles for those who genuinely work records.
A requester crosses into fulfilment-user territory when they are given access to create, update, assign or resolve work records rather than only raising them. The boundary is the write-and-work action on fulfilment records, not the seniority of the person performing it.
The common crossing points are subtle. A manager given a role to reassign tasks within their team is fulfilling work, even occasionally, and may require a licence. A business user handed an agent role to update a single field on a record has crossed the line in licensing terms even if their actual usage is trivial. A user with a role that grants write access to a fulfilment table is, in most readings of the model, a fulfilment user regardless of how often they exercise it.
This is why convenience-driven role grants are so dangerous to the licence position. An administrator who hands out an agent role to spare a user a support ticket, or to let a stakeholder "just have a look and tweak things", may have created a chargeable fulfilment user without anyone recording the decision or its cost. Multiplied across a large organisation over several years, these one-off conveniences accumulate into a population of incidental fulfilment users that nobody intended to license and nobody is actively using as agents. The fix is governance at the point of grant: agent and write-capable roles should require a documented justification, and the question "does this make the person a fulfilment user?" should be asked before the role is assigned, not discovered at the true-up.
This is exactly where ServiceNow's usage analytics and an audit look: at role assignments and the write activity they enable, not at job titles. The buyer-side defence is to map role assignments to actual activity, strip back roles that grant unnecessary write access, and ensure that occasional approvers and reassigners are not carrying agent roles they do not need. The reconciliation method that surfaces this sits in the usage analytics and true-up spoke.
Fulfilment users are counted as named individuals, not as concurrent sessions. Each distinct person who fulfils work in a licensed application needs an entitlement, regardless of how many are logged in at any one time. There is no concurrent-licence relief: a population of 2,000 named agents needs 2,000 fulfilment entitlements even if only 400 are ever active simultaneously.
The count is derived from role assignments and platform activity. This is why the allocated fulfilment-user count on the contract must be reconciled against the active agent population: leavers who retain accounts, duplicate accounts for the same person, service or test accounts assigned agent roles, and over-tiered users all inflate the named count. Each is recoverable, but only if the buyer identifies it before the renewal or true-up frames the number.
The reconciliation of allocated against active is the first and largest cost lever on any ServiceNow estate, and it belongs at the top of the renewal preparation. The package-tier dimension — whether a counted fulfilment user is on the right tier — is treated at ITSM, ITOM, CSM and HRSD package tiers, and the optimisation method at entitlement optimisation and shelfware recovery.
The buyer-side action is a three-step reconciliation: classify every user as requester, approver or fulfilment user by what they actually do; strip back roles that grant unnecessary write access and push casual users to the requester tier; and reconcile the resulting fulfilment count against the contracted entitlement before the renewal window opens.
Done before the vendor frames the conversation, this reconciliation routinely surfaces recoverable seats that fund a materially better renewal position. Done reactively, after a true-up gap is presented, the buyer is defending the vendor's number rather than asserting their own. The asymmetry favours preparation.
The classification should be maintained, not run once. Role assignments drift as people join, leave and change jobs, and a clean reconciliation at one renewal will have decayed by the next if nobody owns it in between. The most disciplined estates treat the requester-versus-fulfilment boundary as a standing governance control: new agent roles require justification, leavers are de-provisioned promptly, and a monthly check reconciles allocated against active so that the renewal reconciliation is a confirmation rather than a fire drill. This continuous hygiene is what keeps the most expensive line in the ServiceNow licensing model aligned to genuine need.
The aggregated reading sits at the ServiceNow knowledge hub and the ServiceNow blog cluster; the engagement opens at the ServiceNow practice or directly at contact.
A fulfilment user is a named agent who creates, updates, assigns and resolves work inside a ServiceNow application and needs a paid licence. A requester is an end user who only raises requests, reports incidents or browses the service catalogue, and is generally covered without a paid fulfilment licence. The distinction is defined by what the user does in the platform, not by their job title.
No. An approver who only approves or rejects requests routed to them is generally covered without a paid fulfilment licence under the standard ServiceNow model, the same way a requester is. Approval is a self-service action, not fulfilment work. An approver only crosses into needing a licence if they are also given roles to create, update or resolve records.
A requester crosses into fulfilment-user territory when they are given access to create, update, assign or resolve work records rather than only raising them. A manager who reassigns tasks, or a business user given an agent role to update a field, may require a fulfilment licence. The boundary is the write-and-work action on fulfilment records, not the seniority of the person.
Fulfilment users are counted as named individuals, not as concurrent sessions. Each distinct person who fulfils work in a licensed application needs an entitlement, regardless of how many are logged in at once. The count is taken from role assignments and platform activity, which is why allocated fulfilment users should be reconciled against active agents before renewal.
Because the paid licence attaches only to fulfilment users, and they typically drive 60 to 80 per cent of total ServiceNow cost. Keeping casual users on the unpaid requester tier, and not over-provisioning fulfilment roles out of habit, directly protects the bill. Misclassifying requesters as fulfilment users is one of the most common sources of overspend on the platform.
The full model: fulfilment users, packages and subscription units.
Which package a counted fulfilment user is licensed to, and at which tier.
How role assignments and activity are read at reconciliation.
A senior Admodum ServiceNow advisor will reconcile your role assignments against actual activity to separate fulfilment users from requesters and approvers. The fulfilment-user reconciliation white paper sets out the method; renewal moments route to the Renewal Programme and the monthly read sits in the newsletter.