Table of content
The information on this page is collected in an attempt to try to correlate and exchange information from different trouble ticket systems.
Trouble ticket system field name correlation
The below table is an attempt to correlate what kind of information different organisations keep in their trouble ticket systems and what they call each field representing that information. The final goal of investigating this information is to make sure that enough information is common between different systems to have a useful exchange of information.
NORDUnet TTS field names
SWITCH field names
The unique ID of the TT source partner
The TT ID that was assigned by the party.
The unique ID of the TT.
The title of the TT.
The type of the TT.
The TT priority.
The TT status.
The source of the ticket.
The date and time when the TT was opened.
The date and time when the TT was closed.
The short description of the trouble.
The detailed description of the incident/maintenance reported in the TT.
The type of the trouble.
Planned (check box)
The impact of the incident/maintenance.
The date and time that the incident/maintenance started.
The date and time when the incident was detected.
The date and time when the incident was reported.
The date and time when the incident/maintenance ended.
The last date and time when the TT was updated.
The window start time in which planned maintenance may occur.
Maintenance window starts
The window end time in which planned maintenance may occur.
Maintenance window ends
Work planned (expected): start time in case of maintenance.
Work planned (expected): end time in case of maintenance.
The NOC entity related to the incident,
The TT IDs of the related incidents.
The necessary actions/events log.
Information about the community that was affected by the incident.
The service that was affected by the incident.
The location (Point of Presence (POP) site, city, etc.)
The NOC network node related to the incident.
The name of the network line related to the incident.
A-end of the link.
B-end of the link.
The engineer that opened the ticket.
The engineers responsible for the incident settlement.
The engineer that closed the ticket.
Encrypted message hash.
The organisation a TT is escalated to
The time a TT was escalated
Estimated time for a planned maintenance
Short report of issue i.e. problem and resolution
Final ticket report
Organisation responsible for resolving issue
Internal information update, e.g. Name and phonenumber of engineers
Next time something is expected to happen with ticket
Next action due date
Messages to management
Time service was actually unavailable
Impact start until
Resolution to the issue
Information about how to verify status of the service
Version of software in e.g. affected equipment
whether SWITCH is responsible or the university itself
whether the ticket is for internal use
problem categories (Fiber, Configuration, Hardware,
Do you want to contribute to this work?
Update the above table or download and fill out the ticket field correlation spreadsheet and send to firstname.lastname@example.org