Skip to main content
The ticket detail page shows the full record for a single ticket and lets you update its state, respond to the requester, and perform lifecycle actions. You reach it at /tickets/:id.

Ticket information

The page loads data from GET /api/tickets/:id and normalizes the raw response. The following fields are displayed:
FieldDescription
uuidUnique internal identifier
labelHuman-readable ticket reference (e.g., TKT-00042) shown in the page header
nombreRequester’s full name (solicitante_nombre)
correoRequester’s email address (solicitante_email)
telefonoRequester’s phone number; a WhatsApp link appears if tiene_whatsapp is true
asuntoTicket subject
categoriaRequest category
descripcionFull problem description (descripcion_problema)
estado_dbCurrent status, shown as a colored pill in the header
prioridad_nomCurrent priority level
area_asignadaArea the ticket is assigned to
creado_enCreation timestamp
actualizado_enLast update timestamp
fecha_limite_slaSLA deadline
sla_horasNumber of SLA hours allocated
ip_registroIP address from which the ticket was submitted
documentoRequester’s ID document number
empresa_departamentoRequester’s company or department

Update form

The Resolución y Respuesta Oficial panel lets you update the ticket. It contains four fields:
estado
string
required
New ticket status. One of: ABIERTO, EN PROCESO, RESUELTO, CERRADO.The form uses EN PROCESO (space) as the send value, not EN_PROCESO. Legacy values PENDIENTE and EN_PROCESO (with underscore) from the API response are automatically mapped to ABIERTO and EN PROCESO respectively when the form loads.
prioridad
string
required
Ticket priority. One of: URGENTE, ALTA, MEDIA, BAJA.
area
string
required
Responsible area. One of: SISTEMAS, SOPORTE TÉCNICO, REDES, INFRAESTRUCTURA, DESARROLLO, MESA DE AYUDA.
respuesta
string
required
Official response or resolution note. Must be between 5 and 5000 characters. This text is recorded in the ticket history.

Saving changes

1

Edit the form fields

Change estado, prioridad, area, or write a response in the respuesta text area.
2

Verify the Save button is enabled

The ACTUALIZAR TICKET button becomes active only when both conditions are true:
  • The form is valid (all required fields filled, respuesta within length limits).
  • The form is dirty (at least one field differs from the loaded ticket data).
3

Click ACTUALIZAR TICKET

The form submits the following payload:
POST /api/tickets/:id/actualizar
{
  "estado": "RESUELTO",
  "prioridad": "MEDIA",
  "area": "SISTEMAS",
  "respuesta": "Se resolvió el problema reinstalando el controlador."
}
4

Confirmation

On success, a snack bar shows the server’s confirmation message and the page reloads with the updated ticket data.

Ticket actions

In addition to the standard update form, the following lifecycle actions are available via TicketsService. Use these when you need to change the ticket’s state beyond a simple status update.
ActionEndpointRequired parameters
AssignPOST /api/tickets/:id/asignaragenteId (string), motivo (string)
TransferPOST /api/tickets/:id/transferirnuevaArea (string), agenteId (string), motivo (string)
ReclassifyPOST /api/tickets/:id/reclasificarnuevaPrioridad (string), nuevaCategoria (string), motivo (string)
PausePOST /api/tickets/:id/pausarmotivo (string)
ReopenPOST /api/tickets/:id/reabrirmotivo (string)
CancelPOST /api/tickets/:id/cancelarmotivo (string), rol (USUARIO or AGENTE)
ArchivePOST /api/tickets/:id/archivarmotivo (string)

Action descriptions

  • Assign — routes the ticket to a specific agent and records the reason in the history.
  • Transfer — moves the ticket to a different area and optionally reassigns it to an agent in that area.
  • Reclassify — changes the ticket’s priority and category without altering its status.
  • Pause — puts the ticket on hold with a mandatory reason; useful when waiting for the requester to provide more information.
  • Reopen — returns a closed ticket to an active state.
  • Cancel — cancels the ticket; the rol parameter distinguishes whether a user or an agent initiated the cancellation.
  • Archive — moves the ticket to the archive with a reason note.

Activity history

The Historial de Actividad panel on the right side of the page shows a chronological timeline of all changes made to the ticket. Each history entry (h) includes:
FieldDescription
h.actor_nombreName of the user who performed the action
h.fechaTimestamp of the action
h.accionAction label (e.g., ACTUALIZACIÓN, TRANSFERENCIA)
h.estado_antes / h.estado_despuesStatus before and after the change
h.area_antes / h.area_despuesArea before and after a transfer
h.comentario / h.respuestaAny note or response text added at the time of the action
The timeline renders entries in the order they are returned by the API, with the most recent action at the bottom.

Build docs developers (and LLMs) love