51.4.2.0 51.4.1.1 51.4.1.0 51.3.0.0 51.2.0.17 51.2.0.12 51.2.0.11 51.2.0.5 51.2.0.2
51.4.2.0 51.4.1.1 51.4.1.0 51.3.0.0 51.2.0.17 51.2.0.12 51.2.0.11 51.2.0.5 51.2.0.2

Database synchronization

When a ticket transitions to a status where toArchive is set to true, it is archived and saved in the database. The storage format for ticket data is similar to that used for alarms:

There are some core fields and metadata.

For the Alarms, the core fields are:

  • The Timestamp

  • The Uuid

  • The User

  • etc.

and the metadata is the alarmData.


For the Tickets, the core fields are all the frozen slots (Template to Scope) and the metadata are all the dynamic slots defined by the template. Only the slot’s values are stored. The flags, facets, and displayName are stored in the TicketTemplate.

Any Dynamic Slot which is not defined by a TicketTemplate won’t be archived


Having a flexible template means that the metadata is flexible too. We’ll see how a change in the Template will impact a ClosedTicket.

Adding a SlotDefinition

Adding a SlotDefinition will not impact the stored data. When you retrieve a ClosedTicket, the new slot will be displayed with its default Value. The slot displayName, its flags and facets will be the one defined in the TicketTemplate.

The only exception is the StrictList which the default value will be set as the StrictListValue are subject to changes.

Updating a SlotDefinition

Likewise, updating a SlotDefinition does not modify already stored data.

Removing a SlotDefinition

When a SlotDefinition is removed from the TicketTemplate, the corresponding metadata in stored tickets is deleted.

The next time you will retrieve the ClosedTicket, the slot won’t even appear.