Incudent closed date is prior than opened date

[SathishB]

In the incident form, the closed date is earlier than the open date. How is this possible? If anyone knows, please help me with this.

[Zach Koch]

This sounds like some customization was done. Are both the fields you mention the OOTB fields and not custom ones? If so, are there any Business Rules that were added/changed regarding these fields?

[wojasso · Accepted solution]

Hi Sathish,

In out‑of‑the‑box ITSM the `opened_at` and `closed_at` fields are system‑maintained: `opened_at` is stamped when the record is inserted and `closed_at` is stamped when the state transitions to "Closed". Under normal circumstances you shouldn’t see the closed date prior to the opened date.

Seeing a closed date earlier than opened is usually due to one of the following:

• **Customisations or imports:** If someone has added a business rule, script include or import that sets `opened_at` or `closed_at` manually, the system will happily store whatever value you give it. Review any custom business rules or data imports that touch these fields.

• **Time zone display differences:** Date/time values are stored in UTC and then translated to the user’s time zone when displayed. If you compare values from users in different time zones you can sometimes see the closed date "appear earlier" than the opened date when in fact the underlying UTC values are correct. Right‑click the field and choose **Show – Date/Time (GMT)** to check the stored value.

• **Re‑opened incidents or manually clearing `closed_at`:** Changing the state back to an in‑progress state clears the `closed_at` value. If someone subsequently sets `closed_at` by a script or through the UI before correcting the opened date, you can get unexpected ordering.

Out of the box the business rule **"Update closed incident"** stamps `closed_at = gs.nowDateTime()` when the state changes to 7 (Closed) and **"Set opened at"** stamps the opened date on insert. I’d start by looking for custom logic that overrides or disables those rules and by validating the raw UTC values in the database to rule out a time‑zone issue.

Hope that helps!