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
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
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
Best Practices
Use Groups for Team-Based Access
Jira groups are best for team-based visibility (Finance, HR, DevOps).
Why: Groups represent organizational teams and are managed centrally in Jira administration.
Example: Show Budget fields to "Finance Team" group
Use Roles for Project-Specific Access
Project roles are best for project-specific responsibilities (Release Manager, Tech Lead).
Why: Roles are configured per-project; same user can have different roles in different projects.
Example: Show Release Notes to "Release Managers" role
Use Permissions for Administrative Access
Jira permissions are best for system-level access control.
Why: Permissions determine what users can do; align visibility with capabilities.
Example: Show Admin Settings to users with "Administer Projects" permission
Combine with Jira Permissions
For editing control, use Jira's native field-level permissions alongside visibility rules.
Pattern:
Rule 1: Show field to Finance group (visibility via Dynamic Screen Rules)
Jira Config: Set field edit permissions to Finance Administrators only
Result: Finance team sees field; only Finance Admins can modify via Jira permissions
Note: Lock Field action is not supported on Issue View. For view-level editing restrictions, use Jira's native field permissions.
Document Access Policies
Maintain documentation about which groups see which fields.
Why: Team members need to know access policies; new admins need reference.
Format:
Field: Budget Information → Visible to: Finance Team, Project Managers
Field: Internal Notes → Visible to: Administrators only
Common Patterns
Pattern 1: Show to Specific Group
Show field only to one team.
Pattern 2: Show to Multiple Groups
Show field to several teams (OR logic).
Pattern 3: Show to Role
Show field based on project role.
Pattern 4: Show to Permission Holders
Show field to users with specific permission.
Pattern 5: Hide from Specific Group
Show to everyone except certain group.
Pattern 6: Role + Context
Show based on user AND issue context.
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.
Role-Based Visibility vs Editing Control
Understanding the difference helps choose the right approach.
Hide field from users
Show/Hide (with user condition)
Field invisible to unauthorized users
Show but prevent editing
Jira field permissions
Field visible but read-only via native Jira config
Show to some users only
Show/Hide (with user condition)
Only specified groups see the field
Combined example:
Dynamic Screen Rules: Show Budget field to Finance group (visibility)
Jira Permissions: Set Budget field edit permission to Finance Admins only
Result: Finance team sees Budget; only Finance Admins can edit
Note: Lock Field action is only supported on Global Issue Create and Issue Transition screens, not on Issue View. For view-level editing restrictions, use Jira's native field permissions.
Related Patterns
Field Locking on Transitions: Lock fields during transitions based on user role (supported on Issue Transition screen)
Progressive Disclosure: Show fields based on context; role-based visibility shows fields based on user
Dynamic Required Fields: Require fields conditionally based on user role (e.g., require approval for non-managers)
Next Steps
Implement your first role-based visibility rule:
Creating Your First Rule - Step-by-step guide
Learn about user conditions:
Defining Rule Conditions - User group, role, and permission conditions
Combine with other patterns:
Field Locking on Transitions - Lock fields during status changes
Progressive Disclosure - Context-based visibility
Understand condition types:
Condition Types - Complete guide to user-based conditions
Ready to implement role-based visibility? Start with a simple group-based rule and expand to complex role + context combinations.
Last updated