Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 12

Ticket Approval?

I see a new feature in 12.5 is "Approvals in Tech UI Workflow function"

I am wondering why tickets need approval in the first place. Can someone give a description of why they are requiring tickets to be approved, and how that process then works?

None of our tickets require approval right now, so I am hoping I am not missing something.


Tags (3)
5 Replies
Level 9

Really depends on your business size and structure.  Our business follows the ITIL framework.  We also have several positions in the organisation that are required to review requests before their are fulfilled.  We have several CABs and approval processes in place to allow this to happen.  For example:

  • Change requests - Change requests (patch rollouts, server replacements, etc) go to our change team for approval.
  • IT Security - requests for new service accounts, opening ports on firewalls, changes to AD GPO's, etc, go to our IT Security officer for approval.
  • Information requests- Requests for information, inter business data transfer, data deletion, etc, go to our information manager for approval
  • Database changes - Changes to live data, database access, etc, go to our DBA for approval
  • Financial - Requests for new hardware / software that incur a cost go to our head of department for approval.
  • AD account changes - Change to a users name and email address (after marriage for example) go to our HR team for approval.
  • Estates issues - Changes to phone systems or office moves go to our estates team for approval
  • Etc

Essentially we use it so the Tech's don't need to chase around for approval emails before taking the ticket forward.  When a ticket hits a group queue we aim to have all the info and approvals in place so work can commence immediately.

Level 14

Ticket approvals are a feature. For example you could set up a ticket type for purchasing something then the approvals would go to a manager or purchasing agent for approval/denial, another example is my company uses it as a process to create accounts for new hires each step goes to a person so first is create network account, second step is go into the ERP system with appropriate rights, third step is setup in our print management system ect. You would see the approvals/denial in the ticket.

In the past (pre 12.5) approvals in the web interface could only be done in the client side of the interface even if the approver was also a tech. So the tech would log in to the tech side of the interface, click the person in the upper right corner to move to their linked client the take care of the pending approvals then click the person icon again to go back to the tech interface it was annoying and somewhat cumbersome.

For reference Approvals are set up in Setup --> Processes --> Approval Process, then those get linked to specific request types.

If you do not use the approval process there is nothing you need to do or worry about.

0 Kudos
Level 12

I can understand the ticket type for purchasing something. I don't understand the need for approval in the creating accounts for new hires.

I would be interested in knowing why you use Approvals for creating accounts and why you do not use Tasks to create child tickets to assign to techs different responsibilities for accounts in the hiring process.

What does Approval do, that Parent/Child tickets do not do? Or what is the advantage of Approval vs Parent/Child ticketing?

0 Kudos
Level 13

I think most people would use Tasks for new hire processes now.

I can basically set it up so that:

  • Someone puts in a ticket with the Request Type selected as "New Employee" and answers any prompted custom fields.
  • In the backend, i have an Action Rule defined that checks all new tickets and if the ticket has a "New Employee" Request Type, then launch the "New Employee" Task.
  • The Task then runs and generates other tickets ('Task Elements') each with their own Request Type, so those could be routed to different groups if needed.
  • Each of those tickets generated by the Task will become Child Tickets of the original "New Employee" ticket.

Perhaps, though, one of those child tickets was to grant access to a files on a file share.  It may be the case that i want someone to Approve all tickets for file access (regardless of whether they are part of a new hire process or not).  So, that's one other use case scenario that might involve Approvals.

Other reasons for requiring an Approval Process (just in general - not necessarily related to new hire stuff) might be:

  • Purchase Requests
  • Vacation Requests
  • IT Change Management requests
  • Database Change requests
  • Office Move requests


Level 14

So the initial reason we chose approval process for new hire and exiting employees instead of a parent/child ticket setup was parent/child was introduced in V12.3 I built the process in V12.1 so parent/child did not yet exist in the product.

Now for the amount of time to build and test I really do not understand the point to migrate and rebuild the process. the only thing I might gain is having some of the later steps be available at the same time instead only being sequential. Other than that I really don't see a difference. The Approval process give an auditable chain of who did what and when so HR likes that.

0 Kudos