Question on Problem Management

The Plumsail website goes in to detail on using the product for Incident Management. Reading through the community topics, it looks like a ticket can be usede to manage an Incident, or a Service Request or a Problem, and only the ticket category changes.
Can a different workflow be attached/configured for each ticket category?

Hi @doilooksensible,
Can you, please, describe your idea in a bit more detail? What kind of workflow do you wish to attach to a ticket based on a category?
Plumsail HelpDesk has triggers that are a very configurable and flexible tool to automate any actions associated with the ticket changes.
You can easily configure a trigger that will start a SharePoint workflow when a Category field in the Tickets list is set to a specific category.
If that's not what you're looking for, please elaborate a bit more. Thank you!

So, our current system uses the term workflow to describe ticket statuses and the permitted transition between them. So for us now, at a simplified level, an Incident must go from Open to Under Investigation, from there may go to either Pending or Closed. However a Problem ticket must go from Open to Under Investigation, and from there may go to Pending, or In Release Cycle. the Problem can only go to Closed from In Release Cycle. Our current system can enforce those different flows for different Ticket typpes.
Hope that is a bit clearer?

Hello! I am sorry for the delay in answering you on this topic: it seems we missed your last reply.

Unfortunately, it is quite difficult to implement such logic of available statuses and even close to impossible. HelpDesk has the following status logic:

  1. When a ticket is created, its status is set to "New" (it's possible to customise the status display name and change it to "Open", but don't change its internal name).
  2. When an agent replied, he sets the status to "Pending" manually (it is possible to create additional statuses like "Under investigation", see the article above).
  3. When a requester added another comment, the ticket's status is changed by our server to "In progress" (so if you set the ticket status to "Release cycle" and the requester replied to it, then it will be changed to "In progress").
  4. After resolving the ticket, the agent saves it as "Solved".

All listed statuses are required for working of SLA policies and we advise you not to change their internal names. You can edit their display names and add new statuses but since the logic of setting "New" and "In progress" statuses is based on our servers, it's impossible to meet your requirement about specific changes (like "Release cycle" can be only "Closed").

I would advise you not to touch the statuses and just add another field to ticket forms - "Stage". There will be available such stages as "Under investigation", "Release cycle" and others if you need. Then implement the approach described in this article to configure cascading lookup. It will also require changing of the "Category" column type to lookup one. So if you select some category on the ticket form then available stages will be filtered. Please let me know whether this approach might work for you and you need help with its implementation.