Skip to main content

Role-Based Visibility

Role-based visibility controls which users see which fields on the form. Instead of showing all fields to everyone, rules adapt field visibility based on user groups, project roles, or permissions, so each person gets a form that fits their job.

Formify enables fine-grained visibility rules, showing fields only to users who need them.

info

Show field only shows; it never hides. A field on the screen is visible to every user until a rule hides it, and a rule does nothing while its conditions aren't met. So the rules on this page use Hide field with the opposite user condition: to show Budget Information only to the Finance Team, hide it from users who are not in the group. Show field is for bringing back a field that another rule hides.

The field must be on the screen: Jira has no setting that keeps a field on a screen but hidden, and a rule can't show a field that the screen doesn't include.

Why Role-Based Visibility Matters​

Problem: Fields that only one team works with (budget, salary, internal notes) appear on every user's form. Forms get crowded with fields most people shouldn't fill in.

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

Benefits:

  • Focused forms - fields of other teams don't appear on a user's form
  • Cleaner forms for most users - irrelevant administrative fields don't clutter the interface
  • Fewer accidental edits - users don't change fields that belong to another team
  • Context-appropriate forms - each user sees fields relevant to their role

Basic Pattern: Show Field for Specific Group​

The simplest role-based visibility rule hides a field from everyone outside one 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: Current user is not in group "Finance Team"
  • Action: Hide field

User Experience:

  • Finance team member opens form → Budget Information field visible and editable
  • Developer opens same form → Budget Information field hidden
  • Developers get a shorter form without financial fields

Show Field for Multiple Groups​

Allow several groups to see a field by hiding it from users who are in none of them.

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
  • Conditions (joined with AND):
    • Current user is not in group "Managers"
    • Current user is not in group "Administrators"
  • Action: Hide field

User Experience:

  • Manager or Admin views issue → Internal Notes visible
  • Regular team member views issue → Internal Notes hidden
  • Internal discussion stays on leadership's view of the issue
info

Each User group condition names one group. Add one condition per group. With the default AND, the rule hides the field only from users who are in none of the groups, so a member of any of them sees it.

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: Current user doesn't have role "Release Managers"
  • Action: Hide 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.

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: Current user doesn't have permission "Administer Projects"
  • Action: Hide field

User Experience:

  • Project Admin views issue → System Configuration visible
  • Regular user views issue → System Configuration hidden
  • Administrative settings kept out of the way of accidental changes

Hide Field from Specific Groups​

Hide fields from certain groups while showing them 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: Current user is in group "External Contributors"
  • Action: Hide field

How it works:

  • Internal employees (NOT in External Contributors) → Executive Summary visible
  • External contractors (in External Contributors) → Executive Summary hidden
  • The field is visible by default; the rule hides it only from the one group

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 (joined with OR):
    • Current user is not in group "HR Team"
    • Category (select list) not equals Hiring
  • Action: Hide 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 requirements are met (user AND context): the rule hides it as soon as one of them isn't

Practical Use Cases​

Software Development Team​

Show the deployment runbook to DevOps only:

  • Condition: Current user is not in group "DevOps"
  • Action: Hide Deployment Runbook field
  • Result: DevOps sees deployment details; other users get a shorter form

Show architecture decisions to senior developers:

  • Condition: Current user doesn't have role "Senior Developers"
  • Action: Hide Architecture Notes field
  • Result: Technical decisions shown to experienced team members

Finance and HR Teams​

Show cost fields to Finance group:

  • Condition: Current user is not in group "Finance"
  • Action: Hide field, with one rule each on Budget, Cost Center and Billing Code
  • Result: Financial fields stay off general users' forms

Show employee details to HR:

  • Condition: Current user is not in group "HR Team"
  • Action: Hide field, with one rule each on Employee ID and Performance Notes
  • Result: HR fields appear only on the HR team's forms

Customer Support​

Show customer contact info to Support team only:

  • Condition: Current user is not in group "Customer Support"
  • Action: Hide field, with one rule each on Customer Email and Phone Number
  • Result: Contact details appear on the support staff's forms only

Hide internal escalation fields from external users:

  • Condition: Current user is in group "External Users"
  • Action: Hide Escalation Path field
  • Result: External users don't see the escalation path on the form

Common Patterns​

Pattern 1: Show to Specific Group​

Show field only to one team.

Condition: Current user is not in group "Finance Team"
Action: Hide field

Pattern 2: Show to Multiple Groups​

Show field to several teams: hide it from users in none of them (AND).

Conditions: Current user is not in group "Managers"
            Current user is not in group "Administrators"
Operator: AND
Action: Hide field

Pattern 3: Show to Role​

Show field based on project role.

Condition: Current user doesn't have role "Release Managers"
Action: Hide field

Pattern 4: Show to Permission Holders​

Show field to users with specific permission.

Condition: Current user doesn't have permission "Administer Projects"
Action: Hide field

Pattern 5: Hide from Specific Group​

Show to everyone except certain group.

Condition: Current user is in group "External Contributors"
Action: Hide field

Pattern 6: Role + Context​

Show based on user AND issue context: hide when either requirement isn't met (OR).

Conditions (OR):
  - Current user is not in group "HR Team"
  - Category (select list) not equals Hiring
Action: Hide 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 field on the screen?
  • 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:

  • Is the rule a Hide field rule with the opposite condition (for example "is not in group")? A Show field rule on its own never hides the field.
  • Is the rule enabled, and is the group/role condition correctly configured?
  • Is there a Show field rule on the same field that brings the field back? Below the Hide rule and with the same Work type selection, it wins whenever both apply; with a different work type selection there is no guaranteed order, so either rule can win

Solution: Review all rules affecting the target field. Open each user condition and check that it picks the intended group or role.

"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 a Hide field rule with a positive group condition. The field stays visible to everyone the condition doesn't match.

Example:

  • Condition: Current user is in group "External Contractors"
  • Action: Hide field
  • Result: Everyone except External Contractors sees the field

Security Considerations​

Hiding Is Not Access Control​

A rule changes what the form shows; it doesn't change who can read the data. Rules don't run in search results, list view, bulk edit, the REST API, Automation or the Jira mobile app, so a hidden field's value stays readable there. Jira also applies the rules after the form or issue page loads, so a hidden field can show for a moment first.

Combine with Jira Permissions​

Jira Cloud has no permissions for individual fields. For data that people must not see, use Jira permissions or issue security levels, and use Formify to keep forms focused.

Best practice:

  • Jira permissions and issue security levels: Control who can see and edit work items
  • Formify: Control which fields each user sees or can edit in the UI

Audit Access Regularly​

Periodically review which groups and roles the rules on sensitive fields refer to.

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.

GoalApproachResult
Hide field from usersHide field (with user condition)Field not shown on the form for those users
Show but prevent editingLock Field (with user condition)Field visible but read-only for the chosen users
Show to some users onlyHide field (opposite condition)Only specified groups see the field on the form

Combined example:

  • Show/Hide: Hide Budget field from users not in the Finance group (visibility)
  • Lock Field on Issue View: Lock Budget for users not in Finance Admins (editing)
  • Result: Finance team sees Budget; only Finance Admins can edit it on the issue page
info

Note: Lock Field also works on Issue View in Jira Software projects, so you can show a field to everyone and let only one group edit it inline (see Locking fields on the Issue View). Status, Due date, Issue type, Resolution, Target start, Target end and Request type can't be locked on Issue View. The lock is UI-only: inline editing in list view cells, bulk edit, the REST API, Automation and the Jira mobile app can still change the field. Use Jira permissions or workflow properties if the data must be protected everywhere.

Field Locking on Transitions: Lock fields based on user role, on transitions and on Issue View

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​