Ticketing
Part of Support platform access
Restricting access to sensitive customer cases
Design a restricted case workflow and check roles, participants, reports, requester access and connected applications.
Put cases needing tighter handling into a defined workflow, then check every route by which their contents may still reach someone outside it. A restricted queue view is insufficient if a broad role, existing participant, report or integration still exposes the case.
Define the intake rule
Tell agents which cases to transfer and who receives them. Examples might include a request containing identity documents, an account takeover report or a complaint involving a staff member.
These examples describe handling needs; they do not assign a legal classification to every such case. Decide what information the first agent should collect, what belongs in the restricted case and what should be kept out of general notes or notifications.
APP 1.2 says an APP entity must take steps reasonable in the circumstances to implement practices, procedures and systems that ensure it complies with the APPs and enable it to deal with privacy inquiries or complaints. Check that the restricted-case workflow aligns with your documented privacy practices.
Implementing a Restricted Case Workflow for Sensitive Customer Information
- Define intake criteriaIdentify cases requiring restricted handling (e.g., identity documents, account takeovers, complaints involving staff).
- Determine data handling requirementsSpecify what information belongs in the restricted case and what must remain excluded from general notes or notifications.
- Align with privacy practicesEnsure the workflow supports APP 1.2 by implementing reasonable practices to comply with Australian Privacy Principles.
Trace the case through reassignment
Before relying on a restricted group, check:
- Who could open the case before transfer, and who can open it afterwards?
- Do CCs, followers or other participants retain access?
- Can administrators, supervisors or broad custom roles still see it?
- What reaches search, notifications, reports, exports and connected apps?
- If a staff member is the requester, can they see internal notes?
Zendesk's Enterprise private ticket groups generally prevent agents outside the group from opening or searching for assigned tickets, subject to role permissions. Admins and Team Leaders can see private tickets by default.
CCs and followers remain when a ticket moves from a public group to a private one. Agents can mention people outside the group, adding them as participants.
An agent working on a Zendesk private ticket is prevented from opening side conversations with team members outside the private group.
On Enterprise plans, Zendesk has settings for internal-note access when an agent is the requester. Broad role permissions may still allow access, so check the account's setting and the actual case path.
Freshdesk separates role actions from ticket scope. Its documented scopes include all tickets, group tickets and assigned tickets; assigned scope can also include tickets where an agent is tagged or has secondary ownership.
A group-scope review is useful, but Freshdesk group scope should not be assumed to provide the same boundary as Zendesk's private-group feature.
Verify Access Control After Reassignment
- Who can open the case before and after transfer?Review role-based permissions and group assignments.
- Do CCs or followers retain access?Confirm participants are removed or restricted post-transfer.
- Can admins or broad roles still view the case?Check default permissions on Enterprise plans.
- Is the case exposed via reports, exports or integrations?Audit all connected apps and reporting tools.
- Can the requester (agent) see internal notes?Verify settings for internal note access when agent is requester.
Zendesk Private Groups vs Freshdesk Ticket Scope
- Access control mechanism
- Private ticket groups (Zendesk) vs. Role-based scopes (Freshdesk)
- Default visibility for admins
- Admins can see private tickets by default (Zendesk)
- CC/follower retention
- Participants remain when moving between public and private groups
- Scope alignment with role actions
- Freshdesk separates scope from role actions; not equivalent to Zendesk’s private groups
- Internal note access for agents as requesters
- Configurable in Zendesk; may still be accessible via broad roles
Keep the handover workable
Name a receiving team and backup owner. Give the first agent a way to transfer the case without copying sensitive details into an unrestricted ticket, and preserve a working reply route for the customer.
When a specialist needs help, share only the details needed through an approved channel.
Use sample tickets containing no real customer information to check opening, search, notification and reassignment paths for relevant roles. Record and fix unexpected access before using the workflow for sensitive material. Repeat the check after changes to roles, groups or integrations.
