Explore work types, fields, and screens in company-managed spaces
10 min
Advanced
By the end of this lesson, you’ll be able to:
- Differentiate work types, request types, fields, and screens
- Describe the purpose of work types, request types, fields, and screens
- Describe the relationship between request and work types
Categorize work with work types
Work types indicate what category of work a work item represents.
👉 For example: The Epic work type represents larger bodies of work, like an entire feature or campaign.
Jira provides default work types for different space types.
- Software spaces use the Epic, Bug, Story, Task, and Sub-task work types.
- Service spaces use the Change, IT help, Incident, New feature, Problem, Service request, Service request with approval, and Support request types.
You can also create new work types.
Work types can have a hierarchical relationship, with some work types as the “parent” and others as the “child.”
👉 For example: Epics can contain standard work types, like Bugs, Stories, and Tasks. Standard work types can contain Sub-tasks.
Work types impact many other space configurations. Jira admins use several different schemes to associate work types with different behaviors and appearances. Work type schemes define which work types company-managed spaces use.
Request types
In Jira Service Management, work types are called request types. Request types function very similarly to work types but have different default configurations. In company-managed service spaces, Jira admins configure request types through work type schemes.
👉 For example: The Service request work type controls configurations for several request types, including Fix an account problem, Get a guest wifi account, and Onboard new employees.
Restricting request types
You might have request types in your service space that only certain people should be able to use. These could be for managers, different teams in your company, or people handling sensitive information.
You can control who can make these requests by limiting access to specific people, groups, customer accounts, or organizations.
If someone doesn’t have access to a request type, they won’t see it as an option to raise a request, even if they search for it. This also applies to admins and agents who might not be able to create or move work items to these restricted request types unless they give themselves or agents access.
Restricted request types can be used in many places, including APIs, but not in email, chat, widgets, or the virtual agent. If a request type is used in these channels and is restricted, it won’t be visible to anyone, even if they have access. This is to ensure that anonymous users can still send requests through these channels.
You can add or remove restrictions on request types to control who has access to raise certain requests.
Provide context with fields
Fields enable users to add and track data on work items.
👉 For example: The Description field enables users to explain what that work item represents.
👇 On work items, users can see and edit many fields to provide context.

Jira provides system fields that are in all Jira sites by default. They are often critical to how work items function.
👉 For example: The Key field must be on every work item in Jira because it assigns a unique identifier to each work item.
Some system fields are required. You can only modify the description (you can’t modify their configuration or delete them). Other fields allow you to make them required, optional, or hidden. Jira admins can create fields to meet their users' needs.
👉 For example: You can create a Location field if your work items commonly include a location.
Throughout Jira, fields impact many views and behaviors, like filters, workflows, and reporting. Jira admins specify the fields available for each work type using work type screen schemes and field configuration schemes.
Determine what users see with screens
A screen is a configuration of fields that users see in a specific work item operation.
👉 For example: The Create screen determines what fields users see when creating work.
👇 This is the Create screen, as seen by a user.

Jira admins configure screens by adding and removing tabs, adding and removing fields on tabs, and changing the order of fields. You can then associate each screen with a work item operation (Create, Edit, or View) in a screen scheme.
👉 For example: Users see the Work Type, Summary, Assignee, and Due Date fields first on the Create screen. But, on the View screen, users see the Work Type, Summary, and Description fields first. Assignee and Due Date are on a different tab.
After you configure screen schemes, you associate the screens with different work types in a work type screen scheme.
👉 For example: The Bug work type should have the Environment field on all of its screens. However, the Story work type shouldn’t include the Environment field on its screens.
Customize what users see in spaces with layouts
You must be a Jira admin to configure most work item behaviors, like screens and schemes, for company-managed spaces. However, company-managed space admins can customize their work items in the layout for work items.
👉 For example: Nathan, a space admin, moves the Fix version field above the Due Date field in his space's layout for work items. In his space's screen configuration, the Due Date field is higher, but Nathan thinks the Fix Version field is more important for his space.
There is one layout for each screen scheme in a space.
👉 For example: Nathan’s space uses two screen schemes: one for the Bug work type and one for the Epic, Task, and Sub-task work types. Nathan has one layout for the Bug work type and another that applies to Epic, Task, and Sub-task.
The layout only impacts the View screen, which appears when users open a work item. The space admin can reorder, add, and remove fields in the layout and hide fields when they’re empty.
Space admins can only add fields that exist in their space’s View screen configuration. If they remove a field from the layout, the field still exists in the View screen configuration. It just isn’t visible for that particular space.
How was this lesson?
next lesson
Configure system fields in Jira
- What are system fields?
- Configure system fields
- Configure values for the Priority field
- Configure values for the Resolution field
- Configure values for the Status field