Topic
- Security & Compliance
Featured Apps
Table of Contents
The problem
IT service desk tickets are built for multiple audiences. A requester submits a ticket and needs to see their request status and any updates relevant to them. An agent works the ticket and needs access to internal diagnostic notes, configuration details, and escalation history. A senior engineer or security lead may need access to restricted system credentials or internal infrastructure details. An external vendor with portal access should see almost none of the above.
Jira Service Management has no native way to segment field visibility within a single ticket by role. A requester with portal access and an internal senior engineer with full Jira access see the same fields on the same ticket. The only workarounds are internal comments, which have no access governance, or separate tickets for internal and external-facing content, which fragments the service record and creates a synchronization problem.
The result is a service desk that either over-exposes internal data to requesters and vendors, or operates with informal conventions about what goes where that have no enforcement mechanism and no audit trail.
How Secure Custom Fields for Jira addresses this
Secure Custom Fields for Jira adds field-level view and edit permissions to Jira Service Management custom fields. Each field carries its own access rules: configured by user, group, or role, independent of project and issue permissions already in place.
A single JSM ticket can contain fields for all audiences simultaneously. Requester-visible fields (request summary, status updates, resolution notes) are accessible to portal users. Agent fields (internal diagnostic notes, triage classification, escalation history) are restricted to the service desk team. Senior engineer or security fields (system credentials, infrastructure configuration details, access escalation approvals) are visible only to the roles that need them.
For each unauthorized user, restricted fields display “You don’t have permission to view the value” rather than the actual content. Admins can configure a masked display as an alternative. Either way, the underlying value is not exposed.
View and edit permissions are separate. A team lead can be given read access to security-sensitive fields for review purposes without being able to modify them. That access structure is enforced at the field level without requiring workaround tickets or informal comment conventions.
What this means in practice
One ticket serves all audiences. The requester sees what they need to track their request. The agent sees the operational detail required to work it. The senior engineer sees the restricted technical fields. The external vendor sees only their request and its status.
No duplicate tickets. No internal comment conventions that rely on agent discipline to enforce. No separate internal projects that fragment the service record. The ticket is authoritative, and field visibility is governed by role.
When a security review or access governance assessment asks who had access to specific credential or configuration fields in service tickets, field-level audit logs provide the answer: a timestamped record of access, not an inference from portal role or group membership.
The governance dimension
For IT organizations with formal access governance policies, vendor access management requirements, or credential hygiene standards, field-level permissions implement access control at the appropriate level of granularity within JSM. Internal system details are restricted to internal roles. Vendor-facing content is governed separately. The service record is complete, and the access boundary is enforced, not assumed.
Secure Custom Fields for Jira adds field-level view and edit permissions, configurable data masking, AES-256 encryption, and audit-ready logs to Jira Cloud. Built on Atlassian Forge. Your data stays within Jira Cloud infrastructure.