How to manage publishing queue tickets in Jira (approvers)

Owned by Marcella Marino
Last updated: 02 Nov, 2023
5 min read

This guide outlines the process for browsing, reviewing and actioning tickets in a Jira service desk.

The Vic Gov CMS has a distributed authoring model which means departments and agencies are responsible for publishing their own content.

To access a queue, visit our federated publishing queue page.

Any new service request must be published/actioned within 2 working days as part of the Service Level Agreement (SLA).

Publishing queue dashboard

Once the queue is open, select Queues.

You’ll see a list of views that you can select to check on the status of various tickets.

To manage any existing or new tickets, select either All open, Assigned to me or Unassigned issues.

Demo of publishing queue dashboard

Hello, my name is Marcella Marino and in this video I'm going to give you a quick demonstration of what the Jira publishing queue looks like and how you can assign yourself a ticket and review that ticket and push it through for approval.

So this is the single digital presence team publishing queue. And as you can see, I have a number of tickets assigned to me. However, if you want to see all of the open issues in your publishing queue, you can simply click on all open issues.

And you'll see in here. Any issues that haven't been closed, they're either on hold waiting for support, they could be waiting on the customer For more information and so on. So this is all of the open issues, but if I head over to.

Any issues assigned to me or see anything that I have in progress on hold or when I'm waiting for a customer.

Reviewing/monitoring a publishing queue

For any new tickets in the queue, you’ll notice that the ticket will appear without an Assignee and the Status waiting for support.

Select the Summary of the ticket to open full details of the ticket, including:

  • Editor name and address: person requesting the update.

  • Page name: title of the page that has been updated.

  • CMS URL: link to the CMS version of the page.

  • Status: this shows the action required for the ticket. It can either be Needs review or Archive.

  • Preview URL: front-end preview of what the page will look like when published.

  • Notes: if completed, this will include any notes from an editor. Note: if a page needs to be reviewed and scheduled to go live at a future date and time, this is where it should be mentioned.

  • SLA: which displays a date and time for ticket resolution.

Before working on a ticket, assign yourself the ticket so no one else begins working on the ticket. Select Assign to me. Alternatively you can assign the ticket to another member of your team by selecting the Unassigned field, typing in a name, and selecting it from the drop-down list.

You can also update the status of the request to In progress until it’s resolved.

The best way to review a publishing request is to check the Notes field to see what the editor requires, then open the CMS URL (which opens the Revisions tab by default) in a new tab.

If the editor has added notes to a request, it will be repeated in the latest Revision notes. The notes can be useful in understanding what has happened to the page. For example, it’s a new page, small update or large update.

  • For a new page, it’s best to do a full review of the content including SEO and accessibility.

  • For an update to an existing page, you can get a sense of how much has changed by comparing the last published version to the latest draft.

For example, the below comparison shows what’s been deleted in red with a strikethrough, and what’s been added in green.

Common actions that you can take after receiving a service request, can include the following:

  1. Review and Publish the page within the CMS > then go back to the publishing queue and change the status of the ticket to Resolved.

  2. Review the page and identify an accessibility issue that needs to be resolved > go back to the publishing queue and add the accessibility breach response and change the status of the ticket to Waiting for customer.

  3. Review the page and notice the content needs more than 5 changes to meet publishing standards > go back to the publishing queue and reply to the customer with next steps > change the status of the ticket to Waiting for customer or On hold.

  4. Review and Archive a page within the CMS > then go back to the publishing queue and change the status of the ticket to Resolved.

  5. Review and Schedule a page within the CMS to go live at a future date and time > then go back to the publishing queue and change the status of the ticket to Resolved.

Capturing service request data

Once you have Resolved a ticket within the publishing queue, you will be prompted to add additional information about the request for accurate and meaningful reporting.

Publishing resolution options include:

  • None

  • Cancelled by customer

  • Refer - analytics

  • Refer - SDP support

  • Refer - enhancement request

  • Refer - dept/agency

  • Refer - other (specify in notes)

  • Info only

  • SPAM mail

  • Duplicate

  • Declined

  • Done

4. Once resolved, the Editor will receive an email notification with the outcome of their request.

Â