Role-Based Visibility

Role-based visibility controls which users see which fields. Instead of showing all fields to everyone, rules adapt field visibility based on user groups, project roles, or permissions—ensuring sensitive information stays protected while keeping forms accessible.

Dynamic Screen Rules enables fine-grained access control, showing fields only to users who need them.

Why Role-Based Visibility Matters

Problem: Sensitive fields (budget, salary, internal notes) appear to all users. Forms expose confidential information to people who shouldn't see it.

Solution: Show fields conditionally based on who is viewing the form. Financial data appears for Finance team, administrative fields for admins only.

Benefits:

Protected sensitive information - confidential fields hidden from unauthorized users
Cleaner forms for most users - irrelevant administrative fields don't clutter the interface
Compliance and security - ensures data access follows organizational policies
Context-appropriate forms - each user sees fields relevant to their role

Basic Pattern: Show Field for Specific Group

The simplest role-based visibility rule shows a field only to users in a specific group.

Example 1: Show Budget Field to Finance Team

Requirement: Budget Information field should only be visible to Finance team members

Rule Configuration:

Screen: Global Issue Create, Issue View
Target Field: Budget Information
Scope: All issue types (or specific types)
Condition: User in group "Finance Team"
Action: Show field

User Experience:

Finance team member opens form → Budget Information field visible and editable
Developer opens same form → Budget Information field completely hidden
Sensitive financial data protected from unauthorized access

Show Field for Multiple Groups

Allow several groups to see a field by using multiple group conditions.

Example 2: Show Internal Notes to Management and Admins

Requirement: Internal Notes should be visible to Managers and Administrators, but not regular team members

Rule Configuration:

Screen: Issue View
Target Field: Internal Notes
Scope: All issue types
Condition: User in group "Managers" OR User in group "Administrators"
Action: Show field

User Experience:

Manager or Admin views issue → Internal Notes visible
Regular team member views issue → Internal Notes hidden
Sensitive discussion visible only to leadership

info

Multiple group conditions use OR logic. If the user is in ANY of the specified groups, the condition is met and the field appears. This makes it easy to grant access to multiple teams without complex configuration.

Project Role-Based Visibility

Use project roles for visibility control specific to project responsibilities.

Example 3: Show Release Fields to Release Managers

Requirement: Release Notes and Release Checklist should only be visible to users with Release Manager role

Rule Configuration:

Screen: Issue View
Target Field: Release Notes
Scope: Bug, Story
Condition: User has role "Release Managers"
Action: Show field

Second Rule for Release Checklist:

Same configuration, different target field

User Experience:

Release Manager views Bug → Release Notes and Release Checklist visible
Developer views same Bug → Release fields hidden
Release management stays with release team

Permission-Based Visibility

Control field visibility based on Jira permissions for fine-grained access control.

Example 4: Show Admin Fields to Project Administrators

Requirement: System Configuration field should only be visible to users with Administer Projects permission

Rule Configuration:

Screen: Issue View
Target Field: System Configuration
Scope: All issue types
Condition: User has permission "Administer Projects"
Action: Show field

User Experience:

Project Admin views issue → System Configuration visible
Regular user views issue → System Configuration hidden
Administrative settings protected from accidental changes

Hide Field from Specific Groups

Inverse pattern: hide fields from certain groups while showing to everyone else.

Example 5: Hide Executive Summary from External Contributors

Requirement: Executive Summary should be hidden from external contractors

Rule Configuration:

Screen: Issue View
Target Field: Executive Summary
Scope: All issue types
Condition: User NOT in group "External Contributors"
Action: Show field

How it works:

Internal employees (NOT in External Contributors) → Executive Summary visible
External contractors (in External Contributors) → Executive Summary hidden
By default field is hidden; rule shows it only to internal users

warning

Using NOT conditions: When using "User NOT in group", ensure the field is hidden by default in Jira screen configuration. The rule then shows it only to authorized users.

Combine Role and Context Conditions

Show fields based on both user role AND issue context for precise control.

Example 6: Show Salary Field to HR for Hiring Issues

Requirement: Salary Range should be visible to HR team, but only on Hiring-related issues

Rule Configuration:

Screen: Issue View
Target Field: Salary Range
Scope: Task
Conditions:
- User in group "HR Team"
- Component = "Hiring"
Action: Show field

User Experience:

HR member viewing Hiring task → Salary Range visible
HR member viewing non-Hiring task → Salary Range hidden
Non-HR member viewing Hiring task → Salary Range hidden
Field appears only when BOTH conditions are met (user AND context)

Practical Use Cases

Software Development Team

Show deployment credentials to DevOps only:

Condition: User in group "DevOps"
Action: Show Deployment Credentials field
Result: Sensitive credentials visible only to authorized team

Show architecture decisions to senior developers:

Condition: User has role "Senior Developers"
Action: Show Architecture Notes field
Result: Technical decisions visible to experienced team members

Finance and HR Teams

Show cost fields to Finance group:

Condition: User in group "Finance"
Action: Show Budget, Cost Center, Billing Code fields
Result: Financial data protected from general users

Show employee details to HR:

Condition: User in group "HR Team"
Action: Show Employee ID, Performance Notes fields
Result: Sensitive HR information limited to HR team

Customer Support

Show customer contact info to Support team only:

Condition: User in group "Customer Support"
Action: Show Customer Email, Phone Number fields
Result: Customer data accessible only to support staff

Hide internal escalation fields from external users:

Condition: User NOT in group "External Users"
Action: Show Escalation Path field
Result: Internal processes hidden from customers

Common Patterns

Pattern 1: Show to Specific Group

Show field only to one team.

Condition: User in group "Finance Team"
Action: Show field

Pattern 2: Show to Multiple Groups

Show field to several teams (OR logic).

Condition: User in group "Managers" OR User in group "Administrators"
Action: Show field

Pattern 3: Show to Role

Show field based on project role.

Condition: User has role "Release Managers"
Action: Show field

Pattern 4: Show to Permission Holders

Show field to users with specific permission.

Condition: User has permission "Administer Projects"
Action: Show field

Pattern 5: Hide from Specific Group

Show to everyone except certain group.

Condition: User NOT in group "External Contributors"
Action: Show field

Pattern 6: Role + Context

Show based on user AND issue context.

Conditions:
  - User in group "HR Team"
  - Component = "Hiring"
Action: Show field

Troubleshooting

"User says they can't see a field they should have access to"

Check:

Is user actually in the specified group/role?
Does their user account have the required permission?
Is the rule enabled?
Does the issue type match the rule's scope?

Solution: Verify user's group membership in Jira Administration → User Management. Check project role assignments in Project Settings → People.

"Field appears for users who shouldn't see it"

Check:

Are there multiple rules affecting the same field?
Is the group/role condition correctly configured?
Is there a conflicting rule showing the field?

Solution: Review all rules affecting the target field. Verify group/role names match exactly (case-sensitive).

"Field is hidden but should be visible to everyone"

Check:

Is there a role-based visibility rule that's too restrictive?
Did you accidentally create a rule for a small group when you meant all users?

Solution: Either delete the restrictive rule, or expand the condition to include all necessary groups/roles.

"How do I show a field to most users but hide from one group?"

Solution: Use NOT condition. Field is hidden by default, then shown to all users NOT in the excluded group.

Example:

Condition: User NOT in group "External Contractors"
Action: Show field
Result: Everyone except External Contractors sees the field

Security Considerations

Fields Are Really Hidden

When a rule hides a field based on user conditions, the field doesn't appear in the UI at all. Users cannot see or interact with it.

Important: This is visibility control, not encryption. Hidden fields are still in the database and may be accessible via API or exports to users with appropriate Jira permissions.

Combine with Jira Permissions

For maximum security, combine Dynamic Screen Rules visibility with Jira's field-level permissions.

Best practice:

Jira permissions: Control who can edit fields
Dynamic Screen Rules: Control who can see fields in the UI

Audit Access Regularly

Review which groups have access to sensitive fields periodically.

Why: Group membership changes over time; access policies should be reviewed quarterly.