Using Self-Service Mode - 2.4
- Former user (Deleted)
- Kathryn Sandin
- Santwana Sarangi (Inactive) (Deactivated)
- Sireesha Dugginapeddi [Appfire] (Inactive) (Deactivated)
On This Page
Video: Self Service Mode Overview
The following video provides a helpful high-level overview of the user features available in Self-Service mode within Delegated Project Admin Pro for Jira. See the documentation in the succeeding sections for additional details.
A Jira Administrator configures Delegated Project Admin Pro for Jira to indicate what can be delegated and who can perform project administrative actions as a Delegated Project Administrator. Once configured, a Delegated Project Administrator will see the Delegated Project Admin option in the sidebar when viewing a project for which they have project administration rights. The project administration rights are based on the Permission Scheme associated with a project and correspond to the "Administer Project" permission.
You will not see this sidebar option if:
- You do not have this permission on the current project
- A Jira Administrator has not delegated anything when configuring the app
- A Jira Administrator has not delegated any project administration capabilities to you or any group of which you are a member
Sidebar (expanded)
Sidebar (collapsed)
Entering Self-Service mode
When a project is in Guided Path mode, Delegated Project Administrators who have been given Self-Service ability by a Jira Administrator will see an Enter Self-Service Mode button in the top right corner of the Delegated Project Admin screen.
After clicking Enter Self-Service Mode, the following screen will appear to warn you of the ramifications of switching to this mode.
Please note that if you (or another Delegated Project Administrator) switches the project to Self-Service mode:
- The project will remain in Self-Service mode until a Jira Administrator, or Delegated Project Administrator with the permission to enable/disable Self-Service, deliberately exits Self-Service mode for the project.
- Other Delegated Project Administrators will be able to view the Delegated Project Admin configuration of the project. However, they will be unable to perform a Self-Service action unless a Jira Administrator has delegated that capability to them.
Overview of Self-Service Mode
By default, a project will be in Guided Path mode, unless the ability to enter Self-Service mode has been granted and a Delegated Project Administrator with the appropriate ability has opted to enter Self-Service mode.
Your view depends on what has been delegated to you
Self-Service mode allows Delegated Project Administrators to do more granular configuration of a project, beyond what can be done in Guided Path mode. What you can do while a project is in Self-Service mode depends on what a Jira Administrator delegated to you, your role on the project, and the groups to which you belong. In addition, it is possible that one Delegated Project Administrator has greater or less capability than another because of different roles on the project or group membership.
It is possible for a Delegated Project Administrator to be unable to do some things or perhaps anything at all in a project if s/he was not delegated any capability pertinent to that mode. If you have been delegated the ability to work in Guided Path mode but not in Self-Service mode, you will still be able to view a project's configuration if the project is put into Self-Service mode, however you will see a warning banner like this at the top of the screen:
What happens when a project is placed into Self-Service mode?
When a project is placed into Self-Service mode, the project's current configuration is analyzed and one or more Process Templates are created to represent that configuration. A Process Template is a collection of schemes that, together, represent the entire behavior of the project. A project will have multiple Process Templates if it uses:
- One set of Create/View/Edit screens for some Issue Types, and a different set for other Issue Types.
- One set of fields for some Issue Types, and a different set for other Issue Types.
- One Workflow for some Issue Types, and a different one for other Issue Types.
This is what the Delegated Project Admin screen looks like once a project has been placed into Self-Service mode:
The various sections of the screen are:
Process Templates — renaming or removing Process Templates, or creating a new Process Template by copying another
Issue Types — adding or removing Issue Types that are available to the project via the currently selected Process Template
Fields — adding or removing a Field from the Create/Edit/View screens, making a Field required or optional, reordering a Field on the Create/View/Edit screens
- Workflow — adding or removing a Workflow step, editing the fields available on a transition screen, reordering the Fields available on a transition screen, or switching to another workflow
Project Permissions — granting or revoking Jira project permissions to a user, role, or group
Project Notifications — adding or removing recipients for a notification that is sent when a workflow transition or issue operation occurs
- Project Priorities — adding or removing priorities that are available for issues in a project
Actions — allow you to either exit Self-Service mode or join an alternate project group if the Administrator has granted those rights to you
A Process Template is a set of configuration options that control the workflows, fields, issue types, and groups that can be applied to a project.
Each of these will be discussed in the succeeding sections.
Connecting Projects with Project Groups
Connecting a project with another causes the projects to become a Project Group. At this point, any change done to one project is done to all of the projects in the same project group. In order to create a project group, the user has to have been granted the "Project Group" permission by the Jira administrator. Once a user has selected to enter Self-Service mode, they are then prompted with a series of dialogs asking them if the project should join a project group.
| Do not join a Project Group | Create a new project group | Join an existing project group |
|---|---|---|
​ | ​ | ​ |
By selecting the independent option, the project does not join a project group. | By selecting this option and specifying a name, a new project | If there are already existing groups and the user is a project administrator on these projects, they can select to join the project group. |
If the user selects to join an existing project group, the system will scan the configuration of both of the project joining and the project group it will join. If it identifies any issues that are incompatible with the project group's configuration, a dialog will be shown and the project will not be able to join the project group:
If the project is able to join the project, but there are changes that will be made to the project due to the various Schemes being different (Workflow Schemes, Issue Type Schemes, etc.) a dialog will be shown with the details of the changes:
The user can at this point select not to add the project to the group by clicking on Cancel.
Working with Process Templates
As mentioned above, when a project is placed into Self-Service mode, the project's current configuration is analyzed and one or more Process Templates are created to represent that configuration. A Process Template is a collection of schemes that, together, represent the entire behavior of the project. A project will have multiple Process Templates if it uses:
- One set of Create/View/Edit screens for some Issue Types, and a different set for other Issue Types.
- One set of fields for some Issue Types, and a different set for other Issue Types.
- One Workflow for some Issue Types, and a different one for other Issue Types.
This is how the Process Templates section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
| Process Templates (2) | The "(2)" indicates the number of Process Templates. By default, the templates are named "Untitled process template 1", "Untitled process template 2", and so on. The name of the currently selected Process Template is shown in the dropdown. Any change made in the Issues Types, Fields, or Workflow sections will affect that Process Template. |
| Click this icon to rename the currently selected Process Template. The following screen will appear. Supply the desired name and click Save.
|
| Click this icon to make a copy of the currently selected Process Template in order to create a new Process Template. The following screen will appear. Supply a name for the new Process Template that will be created from the currently selected one. Click the radio button for any Issue Type you want to be available in the newly created Process Template, and then click Copy.
Please note that if you select an Issue Type that is already being used by any Process Template associated with the project, the selected Issue Type will be removed from that other Process Template so it can be added to your new copy. In addition, if that results in the other Process Template now having no Issue Types associated with it, then you will see a message as shown below. This warns you that the Process Template is unusable, and thus can be removed by clicking the "remove this template" link.  |
| Click this icon to remove the currently selected Process Template. The following screen will appear. If you are sure you want to proceed, click Remove Process Template.
|
| Hover over this icon to see a helpful description of Process Templates. |
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Working with Issue Types
This is how the Issue Types section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
| This indicates an Issue Type available to the project via the currently selected Process Template. In this example, "Sub-task" is the name of the Issue Type and |
| Click this icon to remove the corresponding Issue Type immediately, with no further confirmation. Please note that if you attempt to remove the last Issue Type in a Process Template, you will see the message shown below. You aren't allowed to have a Process Template with no Issue Types, hence it recommends that you remove the Process Template if you no longer need it.  |
| Click this icon to add a new Issue Type to the currently selected Process Template. |
| Click this icon to view the History screen, which shows an audit trail of previous changes made to Issue Types in the currently selected Process Template. The Change Type column indicates if the Issue Type was added or removed. Click the Undo link next to any Issue Type to undo that change.
Changes can be undone in any sequence, and an undo itself can be undone. In the screen above, if the first Undo link was clicked, you would see the following screen confirming that the "Epic" Issue Type was removed.
|
| Hover over this icon to see a helpful description of Issue Types. |
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Working with Fields
This is how the Fields section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
Affects Version/s, | Each of these indicate a Field available to the project via the currently selected Process Template. There will be as many rows as there are Fields in the currently selected Process Template. |
| Click this icon to edit the Field, which causes the following screen to appear.
Through this screen, you can:
Click Close to close the screen when you are through making changes. |
| Click this icon to remove the corresponding Field immediately, with no further confirmation. |
| Click this icon to add a new Field to the currently selected Process Template. |
| Click this icon to view the History screen, which shows an audit trail of previous changes made to Fields in the currently selected Process Template. The Change Type column indicates if the Field was added or removed. Click the Undo link next to any Field to undo that change.
Changes can be undone in any sequence, and an undo itself can be undone. In the screen above, if the second Undo link was clicked, you would see the following screen confirming that the "Sprint" Field was added back.
|
| Hover over this icon to see a helpful description of Fields. |
Field Contexts
When configuring a custom field, a Jira Administrator is able to define a default value and, for fields of type "Select List (single choice)" and "Select List (multiple choice)", a list of options. At that time, the Jira Administrator can choose the issue types to which the configuration applies. The default value, options, and the issue type(s) with which they are associated is collectively known as the "field context." The field context provides the flexibility of having different default values or options for each issue type supported by your Jira project.
Delegated Project Admin Pro for Jira will display a warning at the top of the screen (as shown below) when a Process Template field has a context that is available to only some of the issue types that can be used on that Process Template.
In addition, each field with such a context will have an icon like this next to it in the Fields section of the screen: 
You may want to ask your Jira Administrator to reconfigure the field(s) shown so they are available to all issue types used on that Process Template.
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Working with the Workflow
This is how the Workflow section of the screen appears:
Each item is further described below:
| Item | Description |
|---|---|
| Start Progress | This indicates the name of the Workflow transition. OPEN and IN PROGRESS represent the Status from which and to which, respectively, the transition will move the issue. |
| This icon (shown above for the Resolve Issue transition) is shown when a transition screen is displayed during the transition. This icon is not clickable. |
| Click this icon to add or reposition Fields on the transition screen for the transition. The following screen will appear. Select a Field you'd like to add to the screen and click Add. Once a field has been added, you can click and drag the grabber handle (
|
| Click this icon to remove the transition from the Workflow in the currently selected Process Template, with no further confirmation. |
| Click this icon to add a new step (aka transition) to the Workflow. The following screen will appear.
After making your selections, click Add to add the transition or Close to dismiss the screen without adding the transition. |
| Click this icon to update the Process Template to use a different (pre-existing) Workflow. It is important to note that while Guided Path mode works with Workflow Schemes, Self-Service mode works with Workflows – not Workflow Schemes. The following screen will appear. For any Workflow shown, click Preview to review a visual representation of the Workflow or click Select to have the project begin using that Workflow. Click Close to dismiss this screen.
|
| Click this icon to view the History screen, which shows an audit trail of previous changes made to the Workflow in the currently selected Process Template. The Change Type column describes the type of change and, if applicable, the Transition Name column identifies the transition on which it occurred. Click the Undo link next to any entry to undo that change.
Changes can be undone in any sequence, and an undo itself can be undone. In the screen above, if the first Undo link was clicked, you would see the following screen confirming that the "Ready for review" transition step was removed again.
|
| Hover over this icon to see a helpful description of Workflows. |
If you added a Field and no transition screen previously existed, one will be created and you will now see the 
The visibility of the above icons is based on what administrative tasks the Jira Administrator has delegated, as well as the Delegated Project Admin permissions granted to you or the groups to which you belong. Some Delegated Project Administrators may see more or fewer icons than you because of this.
Working with Project Permissions
To grant or revoke permissions to a project, click the Project Permissions button located at the top of the screen. The Edit Project Permissions screen will appear:
Adding a permission
To grant a permission to a new recipient, click Add permission next to the appropriate permission. The Add Permission screen will appear, allowing you to select the permission type and the recipient.
The Permission Type field supports these choices: Current Assignee, Reporter, Project Lead, Single User, Group, Project Role, Group Custom Field Value, and User Custom Field Value. Please note that:
- When the Permission Type is set to "Group," the groups that can be selected as the recipient are based on what the Jira Administrator has set for the Groups delegation.
- The Group Custom Field Value option will not appear unless the Jira Administrator has delegated one or more fields of type "Group Picker (single choice)" or "Group Picker (multiple choice)."
- The User Custom Field Value option will not appear unless the Jira Administrator has delegated one or more fields of type "User Picker (single choice)" or "User Picker (multiple choice)."
- You cannot select Application Role in the Permission Type field. This is by design, as it would make it too easy for a Delegated Project Administrator to grant a permission to all logged on users. If you are sure that you would like to grant a permission to an Application Role, please ask your Jira Administrator to do this for you using the native Jira Administration screen.
Once you have supplied the Permission Type and recipient, click Add to save your changes or Discard to abandon them.
Removing a permission
To remove a permission, simply click the Delete link alongside the desired permission.
Click Close when you are through adding or removing permissions.
Working with Project Notifications
To add or remove a notification recipient, click the Project Notifications button located at the top of the screen. The Edit Project Notifications screen will appear, listing each event that can be triggered via a workflow transition or an issue operation, along with each recipient for that event.
Adding a recipient
To add a notification to a new recipient, click Add notification next to the appropriate event. The Add Notification screen will appear, allowing you to select the recipient.
The Notification Type field supports these choices: Current Assignee, Reporter, Project Lead, Component Lead, Single User, Group, Project Role, Single Email Address, All Watchers, User Custom Field Value, and Group Custom Field Value. Please note that:
- When the Notification Type is set to "Group," the groups that can be selected as the recipient are based on what the Jira Administrator has set for the Groups delegation.
- The Group Custom Field Value option will not appear unless the Jira Administrator has delegated one or more fields of type "Group Picker (single choice)" or "Group Picker (multiple choice)."
- The User Custom Field Value option will not appear unless the Jira Administrator has delegated one or more fields of type "User Picker (single choice)" or "User Picker (multiple choice)."
Once you have supplied the Notification Type and recipient, click Add to save your changes or Discard to abandon them.
Removing a recipient
To remove a recipient, simply click the Delete link alongside the desired event recipient.
Click Close when you are through adding or removing notifications.
Working with Project Priorities
To add or remove priorities, click the Project Priorities button located at the top of the screen.
Priority Scheme in the self-service
The "Selected Priorities" section shows the priorities present in the priority scheme associated with the project. The "Available Priorities" section shows the remaining priorities available in Jira.
You can drag and drop priorities and click on the save button to save the changes. Priorities present in the "Selected Priorities" section will be associated with the project similar to Jira.
Migration dialog (Similar to the dialog shown in Guided Path mode) will be shown if the source priorities (associated with the project) and the destination priorities (selected priorities for the project) are different and there are some Jira issues with the source priorities.
Priority Migration in the self-service Project Group
There are 3 cases where the priority migration dialog will be shown for the mapping between old to new priorities:
- When a project is joining an existing project group — If the project joining a project group has different priorities than the projects in the project group and has issues with those priorities, the migration dialog will be shown for priority mapping
- When the priority scheme is edited in the "Project Priorities:Edit" dialog
- When a project is exiting a project group and select "Remove ONLY this project from the Project Group"
When a project is exiting the Self-Service and you select the below option:
The following message dialog is shown if there are some projects that have issues that need an old to new priority mapping.
If a user selects Yes, all the projects present in the group will be restored to their original schemes (schemes present prior to joining the Self-Service) and old to new priority mapping will not occur.
If a user selects Cancel, all the projects will be in the Self-Service project group.