Editable Checklist for Tickets

[Mirtaaa]

Hello everyone,
we would like to take a better look at this request - in this regard, I would like to ask for your help in building requirements and specifications.

What we need are examples of the use of such functionality, that focus on user problems, needs and behavior. At this stage, we try to move away from thinking in terms of solutions but more about the problems that appear by not having this feature.

Give as much examples as possible, the more the better. Even if they look similar at first glance, go for it.

Thank You!

[nevena]

Hello,

we need this functionality because often in one request from a client we have a procedure to check and make 10 or more steps. For this purpose, we have made checklist templates in another system and mark them there. Which is quite inconvenient, it would be great to have this functionality in the ticket itself.
Examples where we need checklists:

1. a customer requests a new service (there is a multi-step procedure, depending on the different services.)
2. a customer has a complaint about the operation of some service (FLS has several things to check for a possible problem before transferring a ticket to a higher level support)

[ecomsilio]

Hi @Mirtaaa

Thanks for this update.

In some cases we use tickets as a “work order”. We offer ecommerce services and a work order could be “connect client system to the ebay marketplace”, “enable amazon prime by seller”, “enable product listings for otto” etc.
These work orders are basically a number of standard to-dos and it is important that we carry out all to-dos on the list. To manage these to-dos, we use checklists.
In some cases, it is important to follow a certain order but most often, it is not. In case that the order is important, a numbered/sorted checklist would be nice. In all other cases an unsorted list would be very nice to have.

If we need to gather information from our client in order to fullfill a work order, we often use a checklist to keep track of the information provided. In most cases our client can’t provide all the information at once, so the checklist helps us to keep an overview of the information already delivered and which information is still missing.

Another case we would solve with checklists, is the ability to make sure, everything is checked when a technical error occurs. Let’s say, a product cannot list on ebay and the client doesn’t know why. We then check a list of mistakes that are often made. Is the product active, does it have stock, does it have at least one image, is a salesprice configured for ebay etc. etc. This is just a very simple example which we normaly don’t need a checklist for but it would help with more complicated cases to tick off what possible misconfigurations were checked. Especially if one supporter couldn’t find the error and needs to forward the question to a colleague, then a checklist would already tell, what has been checked.

TL;DR
A checklist would provide a list of to-dos that needs to be done in order to close the ticket.

In a perfect world, there would be some way to store “checklist templates” and just select the template in the ticket and it would then automatically provide the wanted checklist. Eventually as a macro or a action that can be activated by a trigger.

Thanks a lot!
Gijs

[dvanzuijlekom]

The problems we are having are related to compliance (properly document our processes) as well as not being able to have a clear workflow or overview of todo items in a ticket. We have to carry out tasks for certain tickets, and it is important to be able to quickly see if they have been done, when and who has carried these out. Sometimes, we have tickets which have huge amounts of ticket updates from various stakeholders, but very little relevant information to the actual completion of the request.

It would be really nice if a task could be updated from within a note or article, so you could add some extra text, reference or metadata information which is linked to the completion of that specific task item. For instance, I could comment in a ticket that I have sent a request (new ticket) to a third party for approval or to inform them of pending changes, link that ticket and check off a “Request approval” task or a “Notify service provider” task. Ideally, you would be able to click on a task and show the corresponding article.

For example, we have on-boarding tickets for new colleagues, as well as off-boarding for people leaving, and change requests for deployments or infrastructure changes.
We would really like to see customizable task list templates for these, as well as being able to use/combine multiple templates in a ticket.

On-boarding

We’d like to keep records of the platforms a user has been granted access to. If a new developer starts, we would need to:

• Update their Zammad profile information to include their GitHub handle
• Invite them to the organization account on GitHub
• Add their account to specific teams for repository access to work
• Send them a welcome e-mail with some of the basics
• Invite them to the relevant Slack/Signal devteam groups
• Create user accounts for them on Staging application environments
• etc etc

These could all be tasks in the same ticket. Some of these might be sub-tasks in child tickets, but we’d need to tick it off somewhere anyway.

Off-boarding

Whenever someone leaves the organization, we need to lock accounts and clean up all over the place, as well as have a record what has been done and who has done it.

• Remove the user from the GitHub organization
• Lock their user accounts
• Revoke VPN access credentials
• Revoke any issued user certificates
• Remove the user from Signal group(s)
• Revoke access to documentation platforms
• etc etc

Changes

For some change requests to be deployed from Test, to Acceptance and to Production, we’d need:

• An initial request for deployment on Test/Staging from a stakeholder
• A link to the releasenotes and changes
• Instructions on related changes, e.g. database, or environment variable changes/additions

After deployment on Staging:

• An OK from the Quality Assurance team, including their test report
• An OK from the Security team with an optional pentest report
• An OK from the Product Owner to actually deploy on Production

[Turbobommel]

Hey,

for us checklists need to be one of this following two kinds: “Load a checklist template, e.g. User Onboarding” and “Let me do an on the fly checklist and pin it to this ticket.”

It would be nice to load this lists on demand in new or existing tickets and to let triggers pin new checklists to tickets (“Hey, you got a mail from HR with buzzwords ‘new employee’, here is your checklist based on your organization etc”). If all the work is done, let a trigger inform the customer about it.

All kind of checklists should be seen in a very highlighted spot, so everyone does mention it.

Thanks for your work!

[c.adolphs]

I am fully supporting your description!
We are migrating to zammad right now - the biggest feature we are missing is the checklist capability we had in our OTRS-System.

We ordered a modification of an existing todo-list plugin now beeing able to add checklist items to tickets.

I have some commented Screenshots I would like to share with you. The comments are in german right now - I hope, this is not a big problem.

Best regards.
Christoph

Checklist attachment wizard:

Checklist representation in a Ticket (there is also a slim version for integrating into a side bar):

[DB_LBV]

I’m upvoting this request too.

We have many different processes we need to track in Zammad, that have way more steps than only one single task.

In our case, sometimes there can even be different departments involved, so a ticket sometimes needs to create subtickets. In the current implementation it’s not possible to easily see, if a linked ticket is some kind of a subtask, or if the other ticket is linked in some other way.

Even though we are using naming rules for „subtickets“ this doesn’t really help much. We still have to manually track if subtasks are done.

An optional checklist would really help.

It would be great, if you could define different checklist items.

• Normal checklist item
  • editable state
  • „to be done until“ – field: for the ability to use triggers, left blank if not needed
  • optional/mandatory switch (if ticket can be closed if this task is still open)
• Subticket checklist item
  • state depending on the corresponding subticket state
  • „to be done until“ – field (so triggers can be set)
  • optional/mandatory switch (if ticket can be closed if this task is still open)

Additionally it would help to create checklist templates, while still having the possibility to add/remove checklist items if they are needed/not needed in specific tickets

One approach I can think of would be:

Subticket items are a kind of predefined ticket-templates. They first need to be created by admins (or agents), before they can be used as checklist-items. This way it would be possible to use the same task in different checklist templates.

[Andreo]

@DB_LBV

In our case, sometimes there can even be different departments involved, so a ticket sometimes needs to create subtickets.

Everyone has this problem, and it is not solved. And here’s another thing - that if some subtickets must be agreed upon by people from different departments, then you have to create separate tickets for approval.

@DB_LBV

Even though we are using naming rules for „subtickets“ this doesn’t really help much. We still have to manually track if subtasks are done.

We need a visual tree of tickets to understand where the process stopped.

@DB_LBV

Subticket items are a kind of predefined ticket-templates. They first need to be created by admins (or agents), before they can be used as checklist-items. This way it would be possible to use the same task in different checklist templates.

My experience tells me - The to do list is needed most of all for the performer of the task, so as not to forget something. But if the task is capacious, there should be subtickets where the performer acts as a customer.

There are tickets (tasks) for 4 categories:

1. Project (there are a lot of subtickets and they are usually formed in the process of project implementation).
2. Regular (these are tickets that we do with a certain frequency, and the business process for them has already been worked out).
3. On request with a ready business process.
4. On request without a well-established business process.

2 and 4, of course, need to be automated, and for this, a business process must be described and within this process the system will create subtickets.
1 and 3 subtickets are created manually.

And the first step towards the implementation of this idea should be exactly the ticket tree system with thoughtful display. But I’m not sure if this is zammad’s development strategy.

[alexander.bippus]

Thank you at all for this Answer and detailed information.

We do also use Zammad as a daily business tool. It is importent for us to organise our Collegues Problems and Requirements.

We miss a function such described here. It would be so usefull and powerfull at once to have Checklist in the tickets.

Often you need a specific time to get through at ticket. With Checklist you can go ahead only for the task to do without knowing the how Issue.

Think about giving a Ticket to Collegue when someone is on vocation. Instead of scrolling the ticket. Put an Tasklist on the side and each will know what to do next.

Thank you at all.

[shifty]

Hi @all,

we would appreciate it very much if zammad would provide this function. It would help us to create some more complex workflows such as.

A customer writes a ticket stating what positions a new employee will fill. This could be a clerk AND an auditor for example.
Now there are several teams in the company that need to work together on the ticket and do things so that the employee can fulfill both of these roles.

For example,

team 1
is responsible for creating an AD account, assigning an email address, and assigning permissions to a network drive.

Team 2
is responsible for giving the new employee a briefing on the workplace, showing him around the company, etc.

Team 3
trains the new employee.

Now you could create individual objects for each of these tasks, which are then displayed with “done” or “not yet done”. However, this is very time-consuming and requires a lot of time when changes are made. A much better solution would be checklists, which could be created as an automated internal comment above a trigger.
This way, each team could simply check off the items that have already been completed.

[YetAnotherGerrit]

I know it is not exactly the solution you are looking for, but I want to add my personal work-around that is satisfying a lot of scenarios: the text-marker-tool. You can find it in the top-right corner of a ticket:

With that I mark of tasks on a checklist, which can be created by hand, by trigger or macro in tickets. Just by adding a note and listing all task. I know, it’s not editable, but it can be checked off by marking e.g. green.

Maybe this is helpful to some of you.

[shifty]

Thank you very much for your reply.
Yes, that’s the feature we use as a workaround, but let’s face it, the marker does not replace a checklist where you can, for example, or more desirably, track in the ticket who created the account or who created the email address. This tracking would be good for companies that are subject to special requirements such as the BaFin. With the highlighter tool, no one knows who has highlighted what

[Turbobommel]

…and when its finished or not

[DB_LBV]

Another problem with this workaround is: when this checklist is not provided at ticketcreation, you have to scroll down to find a checklist. This way there could even be multiple checklists for whatever reason. It would force you to read through the whole ticket to find out what still needs to be done, instead of just handling an open checklistpoint.

[lxxxxxxx1]

Upvote from us!
A checklist feature would be an excellent tool to organize the tasks that arise within a ticket.

[tholmlun]

Has there been any movement with a checklist feature? It would be a huge improvement to Zammad.

Another, perhaps simpler request, would be to have an editable pinned note or similar that you could use to quickly summarize the status of a ticket, notes about things to be done, etc. When a ticket gets long, it is easy to miss customer direction or decisions that were made throughout the ticket conversation history.

Please add these features to Zammad!

[MrGeneration]

We generally do not communicate any ETAs or roadmaps.
Bumping threads usually doesn’t move stuff up any list so use the heart function on the first article of this thread, please.

[bur]

Cool Idea !
But for us, the highlighter is weird to use.
You never know when it is activated and always double mark the same.
You cannot give colours a name, so you have to write down somewhere what colour means what?

A Checklist is a feature we really miss.
Thats why we are using Planka for Projects and have integrated a field “Planka URL”.

But that is a lot of overhead for small tickets and recurrent tickets.
It would be great to have a Checklist Template, f.e.

"Customer cannot Print

o Check Connection
o Ping IP
o Check Port
o Escalate Level 2 Support"

[BurninLeo]

I think, the data structure for this feature is already available through the “related child” tickets that one can assign to a ticket. Should the “parent/child” relation server another purpose, a new type of relation may be useful, but I don’t think so.

It may be sufficient to display the child tickets in a different way in the parent ticket. This would also grant great flexibility, as a child can have more children, and different parental tickety may need the same task solved.

[bur]

No.
Imagine a Ticket “Deliver and connect a computer”.
I would have to do

• unpack Computer
• Plugin Computer
• Create User “Admin”

But I would never like to have Tickets
“Unpack Computer”
“Plugin Computer”
“Create user ‘Admin’”

For every Ticket where a computer has to be setup.

We also have a lot of recurrent tasks, as onboarding new Users with always the same todo list like

• Create Domain User
• Join Group “Company”
• Create Scan Button on Printer XYZ
• Create PBX User

for now, we use an external kanban board for every Ticket. That absolutely sucks. To Do Lists in Tickets would be an absolute Game Changer for us.