The distinction between a ServiceNow fulfiller licence and a requester licence is the single most consequential boundary in ServiceNow’s licensing model. Get it right, and you pay only for the users who genuinely need operational access. Get it wrong — through over-assignment, custom application design errors, or misunderstood role definitions — and you pay $100–$180 per month for users whose actual platform activity is worth $0. In a 1,000-fulfiller estate, a 20% over-assignment means 200 wasted licences at $240K–$432K per year. This guide explains exactly how ServiceNow defines each role, where the boundaries fall, how the approver licence fits between them, and how to optimise your fulfiller count without creating compliance risk.
ServiceNow’s role-based licensing model creates a stark cost divide between two classes of user. On one side: the requester, who submits tickets, tracks requests, and accesses self-service resources at zero licensing cost. On the other: the fulfiller, who creates, edits, resolves, and manages records at $100–$180+ per month depending on the module and edition tier. Between them sits the approver (also called a business stakeholder), a paid licence that grants approval and reporting access without full operational capabilities.
This boundary is the primary driver of ServiceNow licensing cost for most enterprises. In a typical organisation, 80–90% of employees are requesters (free). The remaining 10–20% — the IT service desk, infrastructure engineers, security analysts, HR case workers, CSM agents, change managers, and developers — are fulfillers (expensive). The total licensing bill is almost entirely a function of how many users are classified as fulfillers and at what tier.
The problem is that this boundary is not as clear-cut as ServiceNow’s documentation suggests. Role assignments are often over-provisioned during onboarding. Custom applications blur the line between requester and fulfiller activity. Organisational changes leave departed employees holding active fulfiller roles. And ServiceNow counts compliance based on role assignment, not actual usage — meaning every user with a fulfiller role counts as a fulfiller, whether they logged in yesterday or two years ago.
Understanding exactly how ServiceNow defines each role, where the boundaries are enforced, and how to manage the fulfiller population is essential for any enterprise seeking to control ServiceNow costs. For a broader view of all licensing models (including consumption-based and unrestricted licensing), see our complete guide to ServiceNow licensing types.
A requester is any user who interacts with ServiceNow exclusively through self-service channels. Requesters can submit incidents and service requests, track the status of their submissions, search and read the knowledge base, access the Service Portal, use the Virtual Agent chatbot (if deployed), and view notifications about their own tickets. Requesters cannot create records on behalf of other users, edit or resolve incidents or cases, approve or deny requests, access operational dashboards or reporting, or manage any platform configuration.
Requester licences are free and unlimited. Every employee, contractor, customer, or external user who only needs to submit tickets and check status qualifies as a requester. There is no licensing cost associated with requesters, regardless of how many there are. For most enterprises, 80–95% of the user base — the general employee population, external customers using CSM portals, or HR self-service users — should be requesters.
Key point: The requester licence is defined by what the user cannot do, not by what application they use. A user accessing the Service Portal is a requester only if the portal restricts their interactions to self-service activities. If the portal — or a custom application surfaced through it — allows the user to perform fulfiller-level actions (creating records for others, editing case details, updating configuration items), ServiceNow may classify that user as a fulfiller regardless of the access channel.
The approver licence occupies the middle ground between requester and fulfiller. Approvers can do everything a requester can, plus: approve or deny requests and change requests, access operational reports and dashboards, view record details beyond their own submissions, and participate in approval workflows. Approvers cannot create, edit, or resolve records, manage incidents or cases, or perform any operational fulfiller-level activity.
Approver licences are paid but significantly less expensive than fulfiller licences. The exact pricing varies by module and deal structure, but approvers typically cost 30–50% less than fulfillers. The approver role is designed for managers, executives, business process owners, change advisory board members, and other stakeholders who need visibility and approval authority but do not perform hands-on operational work in ServiceNow.
The approver trap: Many enterprises are surprised to learn that approvers require paid licences at all. In other platforms, approval workflows can be handled through email notifications or lightweight integrations that do not require a platform licence. In ServiceNow, any user who approves or denies a request within the platform (as opposed to responding to an email notification, which ServiceNow may handle differently depending on configuration) requires an approver licence. This is a significant cost driver for organisations with broad approval hierarchies — particularly in change management, procurement, and HR workflows where dozens or hundreds of managers participate in approval chains.
A fulfiller is any user who needs full operational access to create, edit, resolve, or manage records within their licensed modules. Fulfillers can do everything approvers and requesters can, plus: create incidents, cases, problems, and change requests; assign, escalate, and resolve records; manage the CMDB, service catalogue, knowledge base, and platform configuration; develop and modify workflows, scripts, and integrations; and access the full administrative interface of their licensed modules.
Fulfiller licences are the most expensive user type in ServiceNow, and they are named — each individual fulfiller requires their own licence. Licences cannot be shared between users, floated between shifts, or pooled across teams (unless the organisation has an unrestricted user licensing model, which is a separate structure). The per-fulfiller cost depends on the module, edition tier, and negotiated discounts:
| Module & Tier | Indicative Fulfiller Cost / Month |
|---|---|
| ITSM Standard | $70 – $100 |
| ITSM Professional | $90 – $140 |
| ITSM Enterprise | $120 – $180+ |
| CSM Professional | $100 – $160 |
| HRSD Professional (fulfiller) | $90 – $150 |
| SecOps | $150 – $250+ |
Note: These are indicative ranges from Redress Compliance’s benchmarking database, not official ServiceNow pricing. Actual pricing varies by deal size, volume discounts (40–70% off list for large enterprises), and negotiation. For pricing strategies, see our ServiceNow Pricing and Negotiation: Top 20 Tips.
Key point: ServiceNow determines whether a user requires a fulfiller licence based on the roles assigned to them in the platform, not based on their actual activity. A user with an ITIL role who has not logged in for six months is still a fulfiller from a licensing perspective. This role-assignment-based model is the root cause of the over-assignment problem that affects virtually every enterprise ServiceNow estate.
The licensing classification is driven by role assignment, not by job title, department, or observed behaviour. The mechanism works as follows:
When a user account is created or modified in ServiceNow, the administrator assigns one or more roles to that account. Roles are predefined (such as itil, sn_customerservice_agent, sn_hr_core.case_writer) or custom-defined for specific applications. Each role grants a set of permissions that determine what the user can see and do on the platform.
ServiceNow classifies roles into licensing tiers based on the permissions they grant:
The classification follows a highest-role-wins principle. If a user has both a requester-level role and a fulfiller-level role, they are classified as a fulfiller. If they have an approver role and a fulfiller role, they are a fulfiller. The most permissive role determines the licence requirement.
itil role three years ago for a one-month project and has never logged in since is still counted as a fulfiller.While the fulfiller-requester-approver framework appears straightforward in principle, several real-world scenarios create ambiguity that can result in unexpected licensing costs or compliance exposure.
This is the most significant grey zone in ServiceNow user licensing. When organisations build custom applications using App Engine or Creator Workflows, they create new access patterns that may not fit neatly into ServiceNow’s predefined licensing categories.
A custom facilities management application, for example, might allow any employee to submit a maintenance request (requester activity) but also allow them to update the status of their request, add comments visible to the maintenance team, or upload photos tagged to specific facilities records. ServiceNow may classify some of these actions as record management — fulfiller-level activity — even if the application was designed as a self-service tool.
The risk is amplified by scale. If a custom application is deployed to 5,000 employees and ServiceNow determines that the application grants fulfiller-level access, the organisation faces a potential 5,000-fulfiller compliance gap — an exposure that could exceed $6M per year. This is not a theoretical risk; Redress has seen custom application licensing disputes produce seven-figure compliance findings.
Best practice: Every custom application should receive a licensing impact assessment before production deployment. The assessment should map every user action to a ServiceNow licensing classification (requester, approver, or fulfiller) and ensure that the application’s role assignments are consistent with the intended licensing tier. If the application needs to grant limited record-management capabilities to requesters, work with ServiceNow (or an independent advisor) to confirm the licensing implications before deployment — not after.
Many ServiceNow workflows send approval requests via email, allowing managers to approve or deny requests by clicking a link or replying to the email. The licensing classification of email-based approvals depends on the specific implementation:
If the approval is completed entirely within the email (the user clicks “Approve” or “Reject” in the email body and never logs into the ServiceNow platform), some ServiceNow agreements treat this as requester-level activity that does not require a paid licence. However, if the email links to the ServiceNow platform and the user logs in to review details before approving, this constitutes platform access at the approver level, requiring a paid approver licence.
The distinction is configuration-dependent and contractually nuanced. Review your specific agreement and approval workflow configuration to determine which model applies. If your organisation relies heavily on email approvals to avoid approver licence costs, confirm with ServiceNow (in writing) that this approach is compliant under your agreement.
Users who only view reports, dashboards, or analytics within ServiceNow occupy another grey zone. If the user accesses reports through a Service Portal widget configured for self-service (requester-level access), they may not require a paid licence. However, if the user accesses the standard ServiceNow reporting interface, Performance Analytics, or operational dashboards that display data beyond their own records, they likely require an approver licence at minimum.
Organisations that provide broad dashboard access to management teams — department heads viewing SLA performance, executives viewing service health metrics, business unit leads reviewing change activity — should verify the licensing classification of each dashboard consumer. A seemingly simple act of sharing a dashboard link can create dozens of unexpected approver licence requirements.
Reading knowledge articles is requester-level activity. Creating or editing knowledge articles is fulfiller-level activity. The distinction matters for organisations that rely on subject matter experts across the business (not just IT) to contribute knowledge content. If a marketing manager creates knowledge articles about brand guidelines, or a facilities team member writes articles about office procedures, they require fulfiller licences for the Knowledge Management module — even if they never touch an incident, case, or change request.
Users who view CMDB data (configuration items, service maps, dependency charts) for informational purposes may or may not require a paid licence, depending on how they access the data. Access through a Service Portal widget designed for self-service may qualify as requester access. Direct access to CMDB tables or Service Mapping through the standard platform interface typically requires a fulfiller or approver licence. For organisations with ITOM deployments where infrastructure visibility is shared broadly, this distinction can affect dozens or hundreds of users.
Fulfiller over-assignment is the most common and most expensive licensing issue in enterprise ServiceNow estates. It is also the most preventable. The following analysis illustrates the financial impact at typical enterprise scale.
| Estate Size | Typical Over-Assignment (20%) | Annual Cost at $120/fulfiller/month | 3-Year Cost |
|---|---|---|---|
| 500 fulfillers | 100 excess | $144,000 | $432,000 |
| 1,000 fulfillers | 200 excess | $288,000 | $864,000 |
| 2,000 fulfillers | 400 excess | $576,000 | $1,728,000 |
| 5,000 fulfillers | 1,000 excess | $1,440,000 | $4,320,000 |
These figures assume a mid-range fulfiller cost ($120/month at Professional tier) and a conservative 20% over-assignment rate. At Enterprise tier pricing ($150–$180/month), the numbers are 25–50% higher. And because ServiceNow applies annual uplifts (typically 7–9% if uncapped), the cost of excess fulfillers compounds year over year.
The root causes of over-assignment are consistent across organisations:
When a new employee joins the IT department, they are provisioned with an ITIL role as part of their onboarding. When they leave the department, change roles, or leave the organisation, the ITIL role is not revoked. The provisioning process is systematic; the deprovisioning process is manual, inconsistent, and nobody’s explicit responsibility. Over two to five years, the gap between provisioned and active fulfillers grows steadily.
Contractors and temporary project team members are provisioned with fulfiller roles for their engagement period. When the contract ends or the project completes, their accounts are rarely deactivated promptly. In organisations with high contractor turnover (consulting firms, technology companies, financial institutions), contractor accounts can represent 10–15% of the fulfiller population, with a significant proportion being dormant.
Users accumulate roles over time as they participate in different projects, pilot programmes, or cross-functional initiatives. A change manager might have the itil role, the change_manager role, a custom project management role, and an admin role from a platform migration project. Even if they only actively use one of these roles, the others remain assigned and contribute to licensing exposure. Role creep is especially prevalent in organisations without a regular role review process.
Platform administration teams create test accounts, service accounts, and sandbox users with administrative or fulfiller-level roles for development, testing, and integration purposes. These accounts are frequently never decommissioned after their purpose is served. In Redress’s assessments, enterprises typically have 20–50 test/service accounts with active fulfiller roles that are either completely unused or could be reconfigured with lower-privilege roles.
Not every user with a fulfiller role needs fulfiller-level access. Some users were provisioned as fulfillers because the administrator did not distinguish between approval authority and operational access. A department head who only needs to approve change requests does not need an ITIL role — an approver role is sufficient and significantly less expensive. Reclassifying these users from fulfiller to approver reduces costs while maintaining their required functionality.
Reducing the fulfiller count is the highest-ROI activity in ServiceNow licence management. The following framework, refined across dozens of Redress Compliance engagements, provides a systematic approach.
Generate a report of every user with one or more fulfiller-level role assignments across all licensed modules. The report should include: user name, employee ID, assigned roles, last login date, login count over the past 180 days, last record interaction (ticket touched, change approved, record modified), current employment status (if available through integration with the HR system), and department/job title.
This is the raw dataset from which all optimisation decisions will flow. It must be comprehensive — every module, every role type, every user. Partial extracts that cover only ITSM or only active employees will miss entire categories of over-assignment.
Review each user and assign them to one of five categories:
Active Fulfiller: Regular login and meaningful operational activity within the past 90 days. This user clearly requires a fulfiller licence. No action needed.
Occasional Fulfiller: Infrequent but legitimate usage (1–5 logins in 90 days). Review whether the user’s actual activity requires fulfiller access or could be served by an approver licence. If their only platform interaction is approving change requests, they should be reclassified.
Dormant Fulfiller: No meaningful platform activity in the past 90 days, but the employee is still active in the organisation. Engage the user’s manager to confirm whether the role is still needed. In most cases, dormant fulfillers can be deprovisioned with a safety net: if the user needs access in future, the role can be reassigned within hours.
Ghost Fulfiller: The user has departed the organisation (terminated employee, expired contractor, completed project resource) but their account retains an active fulfiller role. Deprovision immediately. There is no legitimate reason for a departed user to hold a fulfiller licence.
Reclassifiable Fulfiller: The user is active but their actual platform usage is limited to approver-level activity (approving requests, viewing dashboards, reading reports). These users should be reclassified from fulfiller to approver, reducing the per-user cost by 30–50%.
For each user identified as Dormant, Ghost, or Reclassifiable, execute the appropriate action: revoke the fulfiller role (Dormant and Ghost) or replace the fulfiller role with an approver role (Reclassifiable). Document every change — the original role, the new role (or deprovisioned status), the justification, and the date. This documentation is essential for two purposes: it protects the organisation during any future compliance review (demonstrating a systematic, evidenced approach to role management), and it provides the baseline data for the next quarterly review.
For Dormant fulfillers (active employees whose roles have been revoked), implement a 30-day monitoring period. If any deprovisioned user contacts the service desk requesting platform access during this period, their role can be reinstated immediately. In Redress’s experience, fewer than 3% of deprovisioned dormant fulfillers request reinstatement — confirming that the vast majority were genuinely unnecessary. This safety net eliminates the primary objection that prevents many organisations from acting on over-assignment data: the fear of accidentally removing access from someone who needs it.
The gains from a one-time optimisation exercise will erode within 12–18 months if ongoing governance is not implemented. Establish automated processes that prevent re-accumulation:
For a detailed governance framework covering all dimensions of ServiceNow compliance, see our ServiceNow License Compliance guide. For more detail, see our ServiceNow license compliance guide.
The fulfiller concept applies across all of ServiceNow’s user-metered products, but the specific role names, access patterns, and pricing vary by module. Understanding how fulfillers work in each module you license is essential for accurate compliance management and cost optimisation.
The largest fulfiller population in most ServiceNow estates. ITSM fulfillers include service desk agents (Level 1–3), infrastructure engineers, network operations staff, application support teams, change managers, release managers, problem managers, CMDB administrators, and IT leadership with operational platform access. The defining role is itil, which grants full ITSM functionality. ITSM fulfillers are licensed at Standard, Professional, or Enterprise tier. For a comprehensive overview, see our ServiceNow ITSM guide.
Customer Service Management fulfillers (agents) handle customer-facing cases, queries, and service interactions. The defining role is sn_customerservice_agent. CSM fulfiller populations are typically smaller than ITSM but can be expensive per-user due to less volume discounting and higher module pricing. CSM estates are particularly prone to over-provisioning because staffing levels fluctuate seasonally. For module details, see our ServiceNow CSM guide.
HR Service Delivery fulfillers are HR case workers, onboarding specialists, and benefits administrators who manage employee cases and HR workflows. HRSD has a dual licensing metric: HR fulfillers (paid, based on the headcount of HR staff using the platform operationally) and employees (paid, based on the total eligible workforce for HR self-service). The fulfiller count is typically small (50–200 for most enterprises), but the employee metric can be a much larger cost driver.
Security Operations fulfillers are security analysts who triage, investigate, and resolve security incidents and vulnerabilities within the platform. The defining roles relate to security incident response and vulnerability management. SecOps fulfillers are typically the most expensive per-user (often $150–$250+/month) due to the specialised nature of the module and smaller fulfiller populations that receive less volume discounting.
Some users require fulfiller access across multiple modules — for example, an IT operations manager who needs ITSM fulfiller access and ITOM administrative access, or a service desk agent who handles both IT incidents (ITSM) and customer cases (CSM). The licensing implications of cross-module access depend on the contract structure: some agreements charge separately for each module’s fulfiller licence, while others provide bundled pricing for multi-module fulfillers. Review your specific agreement to understand how cross-module access is priced.
For organisations where the fulfiller-requester boundary creates excessive administrative overhead — particularly those with large, fluid workforces where hundreds of users move between requester and fulfiller activity regularly — ServiceNow offers an unrestricted user licensing model.
Under unrestricted licensing, a contracted pool of users can access the platform without individual role-based restrictions. Any user in the pool can perform any action (requester, approver, or fulfiller) without requiring a specific role assignment. This eliminates the need for individual role management and simplifies compliance, but it comes with trade-offs:
Unrestricted licensing makes economic sense only when the ratio of fulfillers to total users is high (above 40–50%) or when the administrative cost of managing individual role assignments exceeds the premium of the unrestricted model. For most enterprises, role-based licensing with disciplined governance is more cost-effective. For a broader licensing model comparison, see our ServiceNow Licensing Guide 2026. For more detail, see our ServiceNow Licensing Guide 2026.
Fulfiller optimisation consistently delivers among the highest returns of any ServiceNow cost management activity. In Redress Compliance’s advisory portfolio:
In every case, the savings were achieved with zero operational disruption. Active users retained full access. Only dormant, ghost, and reclassifiable accounts were affected.
“The fulfiller licence is the atomic unit of ServiceNow cost. Every dollar you spend on ServiceNow user licensing is, at its core, a function of how many fulfillers you have and what tier they are on. Reducing the fulfiller count by 15–20% — which is achievable in virtually every enterprise estate through systematic role auditing — is the single fastest path to material ServiceNow savings. It requires no contract renegotiation, no vendor approval, and no operational change. It simply requires knowing who has a fulfiller role and whether they need it.” — Fredrik Filipsson, Co-Founder, Redress Compliance
A fulfiller licence (also called an ITIL licence or full user licence) grants full operational access to create, edit, resolve, and manage records within licensed ServiceNow modules. Fulfillers include service desk agents, infrastructure engineers, security analysts, HR case workers, CSM agents, and developers. Fulfiller licences are named (one per individual, non-shareable) and are the most expensive user type, typically costing $100–$180 per user per month depending on the module and edition tier.
Yes. Requester licences are free and unlimited. A requester is any user who interacts with ServiceNow only through self-service channels: submitting incidents and service requests, tracking the status of their own submissions, searching the knowledge base, and using the Service Portal. Requesters cannot create records for others, edit or resolve tickets, approve requests, or access operational dashboards. For most organisations, 80–95% of the user base should be requesters.
An approver (business stakeholder) can approve or deny requests, access reports and dashboards, and view record details, but cannot create, edit, or resolve records. A fulfiller has all approver capabilities plus full operational access to create, manage, and resolve records. Approver licences are paid but cost 30–50% less than fulfiller licences. Users who only need to approve requests and view reports should be classified as approvers, not fulfillers — this is one of the most common reclassification opportunities in enterprise ServiceNow estates.
ServiceNow determines licensing based on role assignment, not actual usage. If a user has been assigned a fulfiller-level role (such as the itil role for ITSM or sn_customerservice_agent for CSM), they require a fulfiller licence regardless of whether they have ever logged in or performed any activity. The highest-role-wins principle applies: if a user has both a requester-level role and a fulfiller-level role, they are classified as a fulfiller. This role-assignment-based model is why regular role auditing is essential.
Based on Redress Compliance’s advisory portfolio, enterprises that have not conducted a recent fulfiller audit typically have 15–25% of their licensed fulfillers in a dormant or ghost state — users who have not logged in for 90+ days, have departed the organisation, or have changed to roles that no longer require fulfiller access. For a 1,000-fulfiller estate at $120/fulfiller/month, this represents $216K–$360K per year in wasted licensing spend.
Yes, significantly. Custom applications built on the Now Platform can inadvertently grant users fulfiller-level access by allowing them to create, edit, or manage records in ways ServiceNow classifies as fulfiller activity. If a custom app designed as a self-service tool actually grants record-management capabilities, every user of that application may require a fulfiller licence. This can create compliance exposures in the thousands of fulfillers. Every custom application should receive a licensing impact assessment before production deployment.
Follow a five-step process: (1) extract the complete list of users with fulfiller-level role assignments, (2) categorise each as Active, Occasional, Dormant, Ghost, or Reclassifiable, (3) deprovision Ghost and Dormant users and reclassify appropriate users from fulfiller to approver, (4) implement a 30-day safety net to catch any incorrect deprovisioning, and (5) automate ongoing governance through quarterly reports, HR system integration, provisioning approval workflows, and annual role recertification. This process typically reduces the fulfiller count by 15–25% with zero operational disruption.
Redress Compliance’s ServiceNow advisory team conducts user-level fulfiller audits, identifies over-assignment, and implements governance frameworks that keep your licence count optimised permanently.