EMBS JSD link https://utexas-provost-issues.atlassian.net/jira/servicedesk/projects/EMBSHR/

Personae Access Levels

  1. End user 

    1. Rights:
    2. Persona example: AIS staff requesting Travel approval
    3. Use case example:
  2. Agent
    1. Rights:
    2. Persona example: 
    3. Use case example:
  3. JSD Admin
    1. Rights: Create, edit and modify within the scope of JSD; modify project, forms, form fields; associates configured issue types with forms into request types
    2. Persona example: EMSS BS staff
    3. Use case example:
  4. Full/global Jira Admin 
    1. Rights: add/modify/delete issue types, add/modify/delete workflows. add/modify/delete custom fields, associate fields/workflows/issue types
    2. Persona example: AIS JSD support staff
    3. Use case example:

Documentation Levels/User Personae

  1. End user (ex. EMSS staff requesting travel pre-approval, etc.)
  2. EMSSBS staff (ex. Kristen or Kristin or Kristina–i.e. Finance/Accounting, HR, Operations Leads)

JSD Taxonomy

Issue Type

What is it? 

Where is it? 

First column of Queue listing screen



Rules/Good to know 

Each issue type can have

  • One and only one workflow
  • Multiple Request Types

Customer Request Type

What is it? 

Where is it? 

Create in Project settings


Payments (i.e. vouchers): Travel, Supplies, IT, Entertainment

Rules/Good to know

Must share one workflow 

Fields are assigned here


What is it? 

Where is it? 


Rules/Good to know 


What is it?

A bucket for different request types

Where is it? 

Listed on Project landing page


Rules/Good to know 


Define fields here

Associate screens

Sample form fields

Issue Type Screen Scheme

What is it? 

Where is it? 


Rules/Good to know 

Draft in Progress

JSD Documentation: https://support.atlassian.com/jira-service-desk-cloud/docs/configure-a-service-desk-project-as-an-administrator/

Request Types

Request Types are the things a user can submit for action. For instance:

  • Reimbursement for Food
  • Reimbursement for Travel
  • Payment for Hazardous Material
  • Payment for Group Accommodations

These example Request Types are the children of particular Issue Types.
Or to put it another way: An Issue Type can contain several different Request Types. So in this case, we may name the Issue Type something like Payment/Reimbursement Issues.

Issues Types

An Issue Type has Fields and a Workflow.

Fields are simply the things the users will fill out when submitting the form. Not all fields need to appear on the child Request Types. So to continue the above example:
The Payment for Group Accommodations Request Type may have fields like Airline, Hotel, Conference Fees. The Payment for Hazardous Material Request Type may have fields like Radioactive?, Explosive?, and Half Life of Chemical.

Obviously, those fields for the Hazardous Material Request Type would not apply to the Reimbursement for Food Request Type. But all of these custom fields would belong to the Payment/Reimbursement Issue Type.


Workflows are a series of approvals. Like Fields, Workflows belong to an Issue Type.
A very simple sample approval workflow can be found here:

NOTE: There can only be one Workflow for an Issue Type. As a result, each of the four above Request Types will all go through the same Workflow.

To continue our hypothetical example, at some point, we may realize that unlike the other Requests (Food, Travel, Accommodations) the Payment for Hazardous Material needs to receive an approval from an Security Supervisor.  For this reason, it will need to move to a different issue type such as High Security Payment Requests.


Approval of a Request can be configured in different ways. It can allow the user to select an Approver from a list or it can default to a hidden list of Approvers.

When a request is submitted, the Approvers are notified.


Queues are simply a way to organize Requests. Custom queues allow you to choose the name for the queue, determine what Request Types are filtered into the queue, and what columns appear in the queue.

So for our example, there could be a separate queue for the Payment for Hazardous Material Requests so that those approvers can see just the things they need to work on.

Screens, Screen Schemes, & Issue Type Screen Schemes


Screens can be thought of as forms. Screens group all available Jira application fields and control which fields are displayed to your team at different stages of your workflow (like when creating, editing, or resolving an issue).


Screen Schemes define the Screens your team sees when creating, editing, or viewing an issue.


An 'issue type screen scheme' associates a Screen Scheme (which defines mappings between screens and issue operations) with Issue Types. Hence, an Issue Type Screen Scheme allows you to specify different Screens screens for different issues types when used for the same issue operation (e.g. 'Create Issue') in a given Jira project.

  • No labels