Automatically setting requested for and contact details

within an incident, 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 incident 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 sla status on an incident field, the sla status field will be set automatically from the primary sla associated to the incident this will be updated as the sla updates client response on awaiting client within the standard workflow of an incident there is a workflow status of awaiting client action if an incident is in this status and the requested for user updates the record, the record will automatically go back to a state of work in progress major incident process within the incident record, there are numerous elements that assist with resolving a major incident it should be highlighted, that once an incident has been made a major incident, it cannot be related to another major incident and will automatically update any record's its associated to to flag an incident as a major incident, you need to set the "major incident" field found in the "major incident" tab to yes at this point, there are numerous things that can take part as part of this process relating other incidents it is possible to relate other incidents to a major incident, by selecting add/remove on the related incidents related list in doing so, their status will align to the major incident's status (which will also update their work journal saying as much), assuming that it is not already resolved or closed as well as this, any update to the "major incident journal" on the major incident, will update any of the related incident's client journal automatically once the major incident has been resolved, the related incident's closure notes will be updated with the major incident's closure notes it should be noted that a major incident will never automatically close the related incidents in addition to manually relating an incident to a major incident, or visa versa, it is also possible to do this via sofi and the knowledge article / alert functionality detailed below knowledge article / alert to ensure that major incidents are appropriately communicated, it is also possible to create a knowledge article via a major incident via the "create major incident knowledge" button in doing so, any future incident's that "attach" this knowledge article via sofi to the journal (or interactions) will automatically be associated to the major incident that spawned that article (assuming it is still open) and follow the normal major incident process once created, you can redirect to it automatically, by pressing a "redirect to knowledge article" button that appears on the incident when a record has created a knowledge article the article that is created utilises that reclassification field map table and does the following incident knowledge n/a knowledge base (uses the id from the knowledge base found in the "incident major incident default kb base" application property n/a classification (uses the id from the classification found in the "incident major incident default kb classification" application property n/a archive on source record closure (sets the field depending from the value found in the "incident major incident default kb auto archive" application property the words "major incident " and the short description title the words "major incident " and the short description summary major incident review content id source record n/a knowledge source (incident) resulting knowledge id create standard knowledge article within an incident, it is also possible to create a knowledge article based on content within the incident outside of the major incident process this is done via the config menu found in the top right of the form once created, you can redirect to it automatically, by pressing a "redirect to knowledge article" button that appears on the incident when a record has created a knowledge article this utilises the reclassification field map table and does the following incident knowledge short description summary short description title id source record n/a knowledge source (incident) n/a content (this is made up from the short description, description and closure notes of the incident) resulting knowledge id create related change within an incident, it is possible to create a change from an incident in doing so, the incident 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 incident field change field assignment group assignment group description description priority priority service service short description short description n/a work journal (a combination of the original incident number, classification path and description) related configuration items related configuration items in addition to creating the change from the incident, the incident will automatically resolve when the related change has completed (assuming the incident itself is not already resolved or closed) in addition to this, the incident will receive its closure notes and have work journal updates when it completes create related problem within an incident it is possible to create a problem from an incident in doing so, the incident 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 incident field problem field assignment group assignment group description description priority priority service service short description short description n/a work journal (a combination of the original incident number, classification path and description) related configuration items related configuration items in addition to creating the problem from the incident, the incident will automatically resolve when the related problem has closed (assuming the incident itself is not already resolved or closed) in addition to this, the incident will receive its closure notes and have work journal updates when it closes finally, if the problem's client journal field is updated, it will update the incident's client journal field convert to itsm request within an incident, it is possible to "convert" an incident to request this does not actually convert the incident, but instead creates a request and closes the initial incident 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 incident field itsm request field assignee assignee assignment group assignment group client journal client journal collaborator collaborator description description email email follower follower location location phone phone priority priority requested by date requested by date requested for requested for requestor requestor service service short description short description source source work journal work journal related configuration items related configuration items status (closed) status (new) closure notes (incident has been converted to request req000000) n/a auto closure on resolution once a record has entered the status of resolved, it will auto close by default in 5 elapsed days this behaviour is controlled by two application properties incident auto closure enabled enables / disables auto closure functionality incident auto closure days the number of days (elapsed) that a record needs to be resolved before closing