University CSM Design: Students vs Staff Personas

[Avi Daniely]

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

1. Students
2. 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.

[Avi Daniely]

Thanks for the detailed response.

I appreciate the effort, but I was hoping more for feedback based on real implementations rather than a broad architectural summary. The reply reads a bit like an AI-generated best-practice overview, while my main goal was to hear from people who actually implemented one of these models in a university environment and encountered the practical limitations.

For example:

• students using snc_internal without licensing issues

• Unified Consumer/User in production

• OOTB incident/request access behaviour

• portal and ACL complications

• whether wrapping incidents with CSM cases became painful over time

The theoretical pros/cons are relatively clear already. What I am mainly trying to validate is what worked well in practice and what people later regretted architecturally.