ServiceNow Case Management for Customers: Security and Access Design

Role-Based Access Control Model

Case Management for Customers requires a role model that balances access (enabling teams to do their work) and security (preventing unauthorized actions). Core roles typically include case agents (create, read, update cases), case managers (manage queues, reassign cases, close cases), knowledge contributors (create and maintain knowledge articles), and administrators (configure case workflows, integrations and access policies).

A practical role model for lean teams: separate case agent (read and write their own work, reply to customers) from case manager (can reassign, escalate, close on behalf of agents) from knowledge contributor (can edit articles) from administrator (configuration). Avoid super-admin roles in customer-facing systems; instead, grant specific permissions for specific configuration tasks.

Least Privilege and Segregation of Duties

Least privilege means each role gets exactly the access needed, no more. Customer service agents should not be able to modify case templates or workflows; that’s configuration work. Case managers should not be able to delete customers or change access policies; those are administrative functions. Knowledge contributors should not have case agent access unless they actively handle cases.

Segregation of duties prevents single individuals from performing conflicting actions. For example, separate the person who approves knowledge articles from the person who publishes them. Separate customer creation (sometimes marketing or sales) from customer-facing case agents. This prevents unauthorized changes and ensures change visibility. Document the segregation rules in your access policy.

Customer Portal Access and Authentication

Customers accessing cases through a portal require authentication to ensure they see only their own cases and organizations see only their related customers. ServiceNow typically manages this via customer user accounts (created during case creation or onboarding), directory integration (LDAP, SAML) for known customers, or delegated authentication through partner portals.

Access control at the data level is critical—a customer record should restrict case visibility to that customer and their authorized contacts, not all customers. Test portal access thoroughly: verify customers cannot see sibling organizations’ cases, verify bulk query exports cannot leak data, verify API access enforces data scoping. Audit logs should capture customer login events and data access.

Internal Agent and Manager Access Control

Internal agents and managers need access policies that grant work visibility without exposing sensitive customer data unnecessarily. A common model: agents can see cases assigned to their queue, managers can see all cases in their team or department, specialized teams (billing, technical escalation) see cases routed to their queue. Agents should not casually browse all customer cases or see cases from departments outside their team.

Some implementations require compartmentalized access: healthcare organizations may restrict HIPAA-sensitive case data to teams with HIPAA training and audit requirements. Financial services organizations may restrict credit card or PII data to authorized agents. These roles often require additional access policies and audit logging.

Knowledge Article and Internal Note Access

Published knowledge articles are typically visible to customers through the portal and to agents. Internal notes (not visible to customers) often contain sensitive information—escalation context, customer history, billing notes. Most implementations restrict internal note visibility: agents see notes on cases assigned to them, supervisors see notes across their team, specialists see notes on their specialized cases.

Some notes require compartmentalization. For example, billing or account management notes should be restricted to finance teams or account owners, not all customer service agents. Define internal note access policies during requirements and enforce via role-based access in the platform.

Audit Evidence and Change Tracking

For compliance or dispute resolution, organizations often need to audit case handling—who created a case, when did agents respond, what changes were made and by whom, did the customer escalate to a manager. ServiceNow audit logs capture creation, updates and deletions with timestamp and user. Ensure audit logging is enabled, retained per your retention policy, and reviewed periodically.

Document your access control model and review cycle in writing. A lean team should schedule quarterly access reviews: list active users by role, verify each person’s role matches their job function, revoke stale accounts, document the review. This discipline prevents role creep and helps with compliance audits.

Sorting case data by sensitivity before writing any rule

Access design often goes wrong when teams start with roles and only later ask what data those roles reach. Start with the data instead. Group what a case holds into tiers, decide who genuinely needs each tier, and only then choose the control. The tiers below are a starting point for most customer case workloads, and they will shift once you know what the customer record actually stores.

Once the tiers are agreed, the number of roles often falls. Many teams start with several roles and discover that two of them differ only in a field they never needed to protect.

Testing access as each persona, not as an administrator

Administrators bypass a large share of the restrictions that protect ordinary users, so any test run as an administrator tells you almost nothing about exposure. The sequence below relies on test accounts that mirror the people who will actually sign in. The testing and acceptance checklist places these runs within sign-off.

1. Create a test user for each role and for each external contact type present in the instance. Do not borrow an administrator login for convenience.
2. Open a case from each queue as each persona and record what the form, the related lists, the list views and the attachments show.
3. Repeat the same checks through the customer or partner portal, where the same data appears as a much narrower slice.
4. Export a list view and open a report on the same table as a standard agent. Exports are a route around the form that teams often forget to test.
5. Trigger each notification type for a case the persona should not see, and confirm the message body contains only what that recipient may read.
6. Call the table through each integration account in scope and confirm the account cannot read beyond its stated purpose.
7. Keep the results in a matrix with one row per persona and one column per object, so the next review can repeat the same checks without reconstructing them.

Where data leaks without anyone noticing

Much exposure in case systems is not a dramatic misconfiguration. It is a route into the data that nobody tested because the team was looking at the form.

• Scoping applied to the list view but not to the record, so a user who cannot open the list can still reach a record through a copied link.
• Notification templates that merge internal notes or account fields into an email that leaves the company.
• Attachments that follow the case’s visibility only when the attachment table is scoped too. Otherwise a file uploaded for one customer can be reached from another customer’s case.
• Reporting roles granted for a dashboard that also expose customer identifiers in drill-down.
• Integration users given an administrator role for convenience, so one stolen credential reads everything.

The pattern underneath each of these is that every route into the data needs its own check: the form, the list, the report, the email, the API and the file store. A review that checks only the form has checked one route out of many.

Choosing between role-based and data-based restriction

Most designs combine two or three of these. Choose the lightest combination a reviewer can verify in an afternoon, and document why each heavier control exists.

Keeping evidence and running the review

Audit settings and access reviews answer different questions. Audit logs show what happened to a record. Access reviews show whether the people who could make those changes should still be able to. You need both. A short checklist keeps the quarterly review honest:

• Confirm every user holding a case role still does the job that justifies the role.
• Confirm external contacts whose organization relationship has ended are deactivated.
• Confirm integration accounts still have only the scope recorded in the design.
• Re-run the persona matrix against the current configuration and file the results with the review.
• Check audit settings on any field added since the last review, because new fields often start unaudited.

Where the customer data is regulated, the security owner should decide which of these checks are mandatory and which are good practice. The access recertification post is a useful companion for running the access review itself. That decision belongs in writing, not in the memory of the person who ran the last review.

Access questions that come up in design reviews

Is it enough to hide a field on the form if the underlying table is still readable?

No. A hidden field on the form is still reachable through lists, reports, exports and the API unless each of those routes is restricted. Treat form hiding as presentation and put the actual restriction on the field or the table.

How should a customer who is also an employee of a partner organization be handled?

Give the person one identity with the access that matches the role in each context, rather than two accounts that share a mailbox. Shared mailboxes are a frequent source of access that nobody can explain during an audit.

Who should sign off the access model?

The business owner of the case data signs the tiers, and the security owner signs the controls. Neither signature is sufficient on its own. Record who holds each one in the roles and RACI guide. The business owner knows what the data is for, and the security owner knows how it can be reached.

Does audit logging alone prove that access was appropriate?

It proves what happened, not whether it should have been possible. Logs are evidence after an event, while access design and reviews are the controls that stop an inappropriate event from being possible in the first place.

Changing access rules after go-live is far more disruptive than setting them correctly at the start.