...
The system is set up to make it easy to generate and relate Incidents, Problems, and Changes, and to quickly and automatically propagate workarounds from problems into all related Incidents.
Use Case
Incidents may be created by internal customers through the web portal or via email, or by a technician taking a telephone call from a customer. They may also be created by network monitoring systems configured to send problem reports to the system through one of the standard APIs. A field in the Incident form specifies the reporting source, such as email, web, or phone. A technician may also convert a Service Request to a new Incident via an action button in the SR form if a customer submitted a Service Request when they should really have submitted an Incident. See Details of Incident Rules in the Appendix for more details.
...
If a Support Staff technician creates a record in a status of Closed an email is sent to the customer telling him/her them how to reopen the Incident. This email is sent by a workflow action and is displayed as a checkbox that can be turned off by technician users. This option is set in the workflow options.
...
When a technician works on an Incident, if she they needs more information from the customer in order to take further action, she they can set the status to Pending Customer. A workflow action will automatically send an email to the submitter requesting further information and including the content of the Additional Information field, an append-only field that is used to communicate with the submitter. The email includes a hyperlink for the customer to click to edit the Incident directly.
If the technician needs to reassign the Incident to a different team or person, he or she they simply changes change the Assigned Team and/or Assigned Person field and the system will email the new assignee notifying them of the reassignment (Rule: Incident Edit Actions, Action: I: Notification Actions).
...
When the technician has completed work on the Incident, they set the Status field to Closed and puts put the solution notes into the Resolution field. This triggers a workflow email to the customer that includes the content of the Resolution fields and tells the customer that the request has been completed.
...
If an incident has an underlying problem that needs to be addressed, the technician may quickly convert the Incident into a related Problem record. Or she they may use the Linked Problem lookup to search for existing Problems that may be the cause of this incident, and if one is found, link the Incident to that Problem.
...
The closing email to customers includes a hotlink back to the record if they wish to reopen it and instructs them to explain why they are not satisfied with the solution. Clicking the hotlink will automatically change the "I Would Like To Reopen My Incident" field to Yes, which in turn sets the Status of the Incident to Reopened and notifies the assigned person (Rule: Incident Customer Update Actions, Action: Submitter Update Actions).
Workflow
Ownership
Records in the Incident table are "owned" by the individual submitter. This means each record is associated with a particular employee login and no other "end user" employee will be able to edit that record. All technician users are able to edit any Incident by default.
...