University CSM Design: Students vs Staff Personas

Avi Daniely · 53m ago

We are designing a ServiceNow architecture for a university environment with two main personas:

Students
Staff members

The current requirement is:

Students will use a Business / CSM portal.
Staff members will use Employee Center.
Both students and staff should be able to raise incidents.
Both students and staff should be able to submit requests.
Both students and staff should be able to raise CSM cases.
Both should be able to view and interact with their own tickets.
Neither students nor staff should consume fulfiller licences.

One concern is that, out of the box, a user with only the snc_external role does not appear to have normal access to ITSM incidents. So keeping students purely as external users may not support the requirement to raise and view incidents directly without additional configuration or a different design approach.

We are considering the following options:

Option 1: Internal role for both students and staff

Use snc_internal for both students and staff, and distinguish between the two personas using groups, user criteria, custom roles, or attributes from the identity source.

For example:

Students: snc_internal + student group / student user criteria
Staff: snc_internal + staff group / staff user criteria

This would allow both personas to access self-service ITSM capabilities, while avoiding fulfiller roles such as itil.

Option 2: Internal role for staff and Unified Consumer/User model for students

Use snc_internal for staff members using Employee Center, and evaluate the Unified Consumer/User model for students using the Business / CSM portal.

The question here is whether this is a clean and supported pattern for students who need both CSM case functionality and ITSM/request self-service capabilities.

Option 3: Keep students external and wrap ITSM with CSM cases

Keep students as snc_external users and avoid giving them direct ITSM incident/request access. Instead, students would raise CSM cases, and the fulfilment process would create or manage incidents/requests behind the scenes where needed.

This keeps students clearly external, but may introduce additional complexity around case-to-incident/request processes, visibility, updates, and reporting.

Questions

Which of these approaches is considered the cleanest and most scalable long term?
Is using snc_internal for students acceptable if they are only self-service users and do not receive fulfiller roles?
Has anyone implemented the Unified Consumer/User model for a student population in a higher education environment?
Are there any licensing implications we should be aware of for students or staff using portals only?
Is wrapping ITSM incidents/requests with CSM cases a recommended pattern, or does it create unnecessary complexity?

Any real-world experience or recommendations would be appreciated.

Ana39 · 10m ago

This is actually a very common higher-ed ServiceNow architecture problem, and honestly your thinking is already aligned with how most mature university implementations evolve over time.

Short version:

Option 1 is usually the cleanest long-term architecture.
Option 3 is often overengineered unless students are truly “customers” external to the institution.
Unified Consumer/User can work, but adds identity/model complexity that many universities later regret unless they have a very strong CSM-first strategy.

The core architectural question

The real question is not:

“Are students external?”

It’s:

“Do students behave operationally like enterprise users?”

In universities, the answer is usually:
✅ yes.

Students:

authenticate with university identity
consume IT services
request hardware/software/access
open incidents
interact repeatedly with internal support teams
often need knowledge, approvals, workflows, lifecycle visibility

Operationally, they behave much closer to employees than anonymous customers.

That’s why many universities eventually treat:

staff
faculty
students

all as internal self-service users, while still separating experiences logically.

My recommendation

✅ Recommended Pattern: Option 1

Use snc_internal for:

students
staff
faculty

WITHOUT fulfiller roles.

Then separate personas using:

groups
departments
user criteria
ACL conditions
audience criteria
portals/experiences

This is the cleanest and most maintainable model long-term.

Why Option 1 scales best

1. ITSM is naturally designed for internal users

You already identified the biggest issue:

snc_external users do not naturally fit ITSM self-service.

You can force it…
…but you end up fighting:

ACLs
widgets
portal visibility
approvals
activity streams
request visibility
attachment access
notifications
APIs

forever 😅

2. Avoids unnecessary CSM wrapping

If students need:

incidents
requests
approvals
catalog
KB
interactions

then wrapping everything in CSM Cases becomes:

duplicate lifecycle management
duplicate SLAs
duplicate reporting
duplicate state models
integration overhead
synchronization headaches

Eventually people ask:

“Why do we have Cases creating Incidents creating Tasks for internal university users?”

…and the answer becomes:

“Because of licensing fears from 3 years ago.” ☠️

3. Employee Center already solves most of this

Employee Center is fundamentally:

audience-driven
persona-driven
user-criteria-driven

You can absolutely create:

student experience
staff experience
faculty experience

without separate identity models.

Licensing reality (VERY important)

This is the part where universities sometimes get scared unnecessarily.

Having snc_internal does NOT automatically mean fulfiller licensing.

The expensive licensing is typically tied to:

itil
fulfiller roles
agent roles
workspace usage
operational roles

NOT simple self-service access.

A user who:

submits incidents
submits requests
views own tickets
uses Employee Center

is generally considered a requester/self-service user.

Still:
✅ validate with your ServiceNow AE/licensing team
because contracts vary.

But architecturally:
using snc_internal for self-service-only users is extremely common.

About Unified Consumer/User model

This is where things get interesting.

Unified Consumer/User is powerful BUT…

It’s best when you truly have:

B2C
external citizens
patients
retail customers
alumni
applicants
parents
non-enterprise identities

not heavily operational university populations.

Why universities struggle with Unified Consumer/User

You end up with users who are simultaneously:

student
employee
teaching assistant
alumni
applicant

And then:

consumer records
user records
identity linking
duplicate profiles
ACL divergence
portal fragmentation

become painful.

My honest architectural threshold

I’d only recommend Unified Consumer/User if:

the university is heavily investing in CSM as a strategic platform
AND
students are treated organizationally as customers
AND
there are significant non-employee populations

Otherwise:
it’s complexity without much benefit.

Option 3 (CSM wrapper model)

This is viable…
but I would only use it if:

Students are truly external

Example:

public citizens
prospective students
applicants
external training customers
partner institutions

NOT day-to-day enrolled students.

Why Option 3 becomes painful

You now manage:

Case lifecycle
Incident lifecycle
synchronization
comments/work notes mapping
attachment propagation
state mapping
SLA coordination
dual reporting
analytics fragmentation

And eventually:
support agents start working mostly in incidents anyway.

So the Case becomes a shell around the real work.

What most successful universities do

Very commonly:

Persona Model

Staff	Internal
Faculty	Internal
Students	Internal self-service
Applicants	External/Consumer
Alumni	External/Consumer
Public users	External/Consumer

That split tends to age very well.

What I would implement

Recommended Architecture

Identity

All authenticated university populations:

snc_internal
no fulfiller roles

Experience Layer

Use:

Employee Center
separate experiences
user criteria
audience targeting

ITSM

Direct:

incident creation
request catalog
knowledge
approvals

CSM

Use CSM for:

true external engagement
applicant services
alumni
public-facing services
partner organizations

NOT as a wrapper around basic student ITSM.

One subtle but important point

You do NOT need separate portals just because personas differ.

Modern Employee Center can handle:

different menus
different catalogs
different KBs
different branding
different homepage content

via audience targeting.

A lot of universities simplify dramatically by:

consolidating experiences
not splitting portals too early

My final recommendation

Best long-term architecture

✅ Students = snc_internal self-service users
✅ Staff = snc_internal self-service users
✅ No fulfiller roles unless operational work is performed
✅ Use Employee Center + audience segmentation
✅ Use ITSM directly for incidents/requests
✅ Reserve CSM for genuinely external populations