In the current state, here is the problem set:
- In order for an agent to be able to link a problem, the type field is required on a ticket from.
- common language issue where a customer (end-user) say they have a "Problem", even when ITSM / ITIL language defines the request as an Incident and the agent accidentally sets the type to the problem. The leads to bad data and ticket hygiene.
- If the type field is exposed, an agent can change the type without changing to the correct form to expose the required fields that help feed our product teams and QA teams.
- If an admin uses triggers to set the Type based on the Form being used (This is great by the way) and hides the Type field, the Link field will never be displayed in the ticket being worked on. This forces the agent to exit the ticket and then use the bulk edit to Link to the correct problem. Wall clock, 10-15 seconds of lost time.
- Requiring the Type dropdown to expose the Link to Problem field limits the ability of admins to work around the lack of granular permissions for changing the ticket type. (I use forms and triggers to work around this limitation)
In the Ideal state:
- The "Link to Problem" field can be used as a Conditional field. When an agent ticks an admin defined checkbox, the Link to Problem field can be exposed without the Type being on the ticket form.
- The "Link to Problem" can be displayed even when the Type dropdown is not displayed in the Ticket Form.
- There is configurable Role permission for "Role can change Ticket Types." This would help ensure good ticket and data hygiene.
Some would argue this is a training issue. But since we are all human and prone to error, it is key that we as admins be able to build processes based on triggers, ticket forms, and permissions that limit or remove the ability to error or intentional try and game the SLA policies that differ from a Question, Incident, etc...
Por favor, entrar para comentar.