Discover Jira Cloud products
Learn more about Jira Cloud products, features, plans, and migration.
Use this page as a reference for the default configuration (including custom fields, issue types, workflow, and permission scheme) of your Jira Service Management projects:
If required, Jira Service Management will create the following custom fields:
Custom field | Type | Notes |
---|---|---|
Viewport Origin | String value, storing the 'Portal' and 'Request Type' if a request was created through the Customer Portal. | Issues must have this field to be a Jira Service Management request. |
Time to resolution | An SLA field, stored in JSON format. | This field stores SLA information for time until a request's resolution is set. Learn more about SLAs. |
When a new project is created, Jira Service Management will create a new issue type scheme for the project with the name Jira Service Management Issue Type Scheme for Project <PROJECT KEY>. Jira Service Management also creates the following issue types and associates them with the issue type scheme:
'IT Help'
'Purchase'
'Change'
'Fault'
'Access'
New Jira Service Management projects come with 2 request types set up and each of them maps to an issue type:
Request type | JIRA issue type | Description |
---|---|---|
Get IT Help | IT Help | Get assistance for general IT problems and questions [example] |
Request a new account | Access | Request a new account for an internal system [example] |
Jira Service Management creates and associates each new service project with a default workflow, named
Jira Service Management IT Support Workflow generated for Project <PROJECT KEY>. A corresponding workflow scheme will be created, named JIRA Service Management IT Support Workflow Scheme generated for <PROJECT KEY>. The workflow scheme by default
Note: When you enable the service management functionality on an existing project, the project will keep its existing workflow scheme, but you can change it on the workflow schemes page in the Jira administration console.
The default workflow has a few default statues and the status names are converted into customer-friendly names on the customer portal via workflow status mappings. Status mappings can be specified per request type. The 2 default request types have the following workflow status mappings:
Default workflow status | Description | Status shown to customers (on Customer Portal and in notification emails) |
---|---|---|
Waiting for Triage | The initial status when requests are created. | Waiting for Support |
Waiting for Support | After requests have been triaged and each time the customer/reporter is waiting for a response. | Waiting for Support |
Waiting for Customer | After an agent has actioned a request and is waiting for a response from the customer/reporter. | Requester Action Needed |
Resolved | When the request has been marked as resolved. | Resolved |
At installation time, Jira Service Management creates a global permission named Jira Service Management agent access. If agent based pricing is enabled for the instance, users who require access to agent views or functionality need to have this permission. The number of users who are granted this permission determines how many agent licenses are used on the system.
This page shows the permission configuration for a standard service project permission scheme.
To see an overview of how permissions are set up for a service project, see Permissions overview.
If you want to customize the permission scheme, see Customizing Jira Service Management permissions.
If you run into permission-related problems, see Resolving Jira Service Management permission errors.
Jira Service Management introduces the Service Desk Customer - Portal Access security type. A security type is a concept that allows restriction of users to certain permissions, examples of security types include project roles and groups. Service Desk Customer - Portal Access is a special security type that only applies to users while they are viewing the Customer Portal - it was created specifically to allow customers to use the Customer Portal without giving them access to the internal service project view and your other Jira applications.
Was this helpful?