Setting up request types

Customizing the fields on a request type

The fields and descriptions that appear in a request type are based on the field configured for the issue type (that is, the issue type the request type is based on). 

You use the Fields tab on the Customer Portal to change the default JIRA field names to more customer friendly language. For example, the "Summary" field appears as "What do you need?" for customers. 

You can also keep fields hidden but available on the request type so that their value can be used for other processes. For more details about how different types of fields work in JIRA Service Desk, see Hidden fields and unsupported fields.

If the issue type doesn't have the fields you need, you must add a field to the JIRA issue type that the request type is based on. If the issue type uses multiple screen schemes, the new field must be available in the create screen. See Configuring Fields and Screens.

Customizing the workflow statuses for a request type

JIRA Service Desk uses the workflow associated with the request's issue type for the flow of the request.

You can re-map the default workflow statuses to more customer friendly statuses that will appear for customers, and you can also map multiple statuses to a single customer status to simplify the appearance of the workflow. Use the Workflow Statuses tab on the Customer Portal designer to customize the workflow that customers will see. 

Only changes between these customer-visible 'status names' will be reflected in the Customer Portal and its notifications (e.g. a transition between two workflow statuses can be hidden on the Portal by giving them the same 'status name'). Customers receive email notifications when they raise a request through the Customer Portal, when their request is resolved, when another user comments on their request, and when there is a change in the 'status name'.

When an issue is created through the Customer Portal, JIRA Service Desk suppresses emails that would be sent to the reporter by the project's notification scheme. In this case the issue reporter is also prevented from becoming an auto watcher on the issue to prevent duplicate notifications.

If you need to change the workflow of a request, you must edit the workflow associated with the service desk project. You can find this workflow on the project administration section of the service desk project.

Hidden fields and unsupported fields

Each request type in a service desk is based on a JIRA issue type. Every JIRA issue type has a set of allowed (and possibly required) fields associated with it. As you set up the request type, you can choose to include fields that are hidden on the Customer Portal but still provide a value to assist with your internal processes and reporting. For example, you might want to set the value of the "Label" field as "hardware" for the "Request new hardware" request type, and set the value as "software" for the "Request new software" request type.

Some fields used by an issue type are not supported for use in the Customer Portal; if you include these fields on a request type, they will automatically be added to the Hidden fields with preset values section and you'll be required to set a value for them.

Other fields aren't supported for use in JIRA Service Desk.

These fields can be added to the request type and given a preset value, but you cannot make them visible on the Customer Portal:

• Assignee
• Linked issues
• Any fields that are defined by other add-ons in JIRA

These types of fields can't be added to a request type and won't appear in the in the "Add a field" dialog:

• Issue type
• Log work
• Reporter
• Security level
• Time tracking

How notifications work for a service desk project - versions 1.2.6 and later

Two settings impact how notifications work for a service desk project:

• The Notifications setting for JIRA Service Desk at the system level. When this setting is enabled, JIRA Service Desk notifications overwrite the JIRA notification scheme that is associated with the project for notifications that are sent to customers, (i.e. issue reporters through the Customer Portal). This means that when the JIRA Service Desk setting is enabled, JIRA Service Desk controls the notifications for customers and the JIRA notification scheme controls the notifications for the other JIRA users. When the JIRA Service Desk setting is disabled, the JIRA notification scheme takes effect for all users. 
• The JIRA notification scheme that is associated with the project. 

The following table explains how notifications work. 

How notifications work for a service desk project - versions before 1.2.6

Two settings impact how notifications work for a service desk project:

• The Notifications setting for JIRA Service Desk at the system level. When this setting is enabled, JIRA Service Desk notifications overwrite the JIRA notification scheme that is associated with the project for notifications that are sent to issue reporters. Reporters receive email notifications when the following events happen:

• • when they raise a request through the Customer Portal, 
  • when their request is resolved, 
  • when another user comments on their request, and 
  • when there is a change in the 'status name'.
• The JIRA notification scheme that is associated with the project. If the project has no associated JIRA notification scheme, no notifications are sent. 
  • If the Notifications setting for JIRA Service Desk is enabled, the JIRA notification scheme takes effect for all of the other events and the other users. 
  • If the Notifications setting for JIRA Service Desk is disabled, the JIRA notification scheme works as defined. 

Notes on service desk notifications - versions before 1.2.6

When the Notifications setting for JIRA Service Desk at the system level is enabled, take note of the following: