Within a Ticket, when a requestor has been set and a requested for has not been set, the requestor will copy over to the requested for automatically. 

In addition to this, every time a requested for has been set it will automatically populate the location, phone and email address of that user into the appropriate fields.  It copies it over, as it will allow the service desk to confirm any contact details in the system and update as required specific to this record, if for whatever reason the Ticket is about that issue. It should be noted though that every time a requested for changes, you will lose any changes in the location/phone/email fields.

Finally, if the requestor or requested for is a VIP (which is a flag found on the user record), the field itself will be highlighted with a purple border.

On an Ticket field, the SLA status field will be set automatically from the primary SLA associated to the Ticket.  This will be updated as the SLA updates.

Within the Ticket record, there are numerous elements that assist with resolving a major ticket. It should be highlighted, that once a Ticket has been made a major Ticket, it cannot be related to another major ticket and will automatically update any record's its associated to. 

To flag a Ticket as a major ticket, you need to set the "Major ticket" field found in the "Major Ticket" tab to yes.  At this point, there are numerous things that can take part as part of this process. 

It is possible to relate other Tickets to a major Ticket, by selecting add/remove on the related Tickets related list.  As well as this, any update to the "Major Ticket journal" on the major Ticket, will update any of the related Ticket's client journal automatically. Once the major Ticket has been resolved, the related Ticket's closure notes will be updated with the major Ticket's closure notes.  It should be noted that a major Ticket will never automatically close the related Tickets.

Within a Ticket, it is also possible to create a knowledge article based on content within the Ticket outside of the major Ticket process. This is done via the config menu found in the top right of the form.

This utilises the reclassification field map table and does the following.

Within a Ticket, it is possible to create a change from a Ticket.  In doing so, the Ticket will be automatically associated to the change and certain fields will be copied over automatically. This is done via the config menu found in the top right of the form.

This utilises the reclassification field map table and does the following. 

As the Ticket process is meant to be a more basic variant of a full on Incident/Request process, it does not automatically resolve once a change has been closed.

Within a Ticket it is possible to create a problem from a Ticket.  In doing so, the Ticket will be automatically associated to the problem and certain fields will be copied over automatically. This is done via the config menu found in the top right of the form.

This utilises the reclassification field map table and does the following: 

As the Ticket process is meant to be a more basic variant of a full on Incident/Request process, it does not automatically resolve once a problem has been closed.

Once a record has entered the status of resolved, it will auto close by default in 10 elapsed days. 

This behaviour is controlled by two application properties: