What could be the reason for showing Incident opened data later than Resolved/Closed date

[reddyvenugo]

Ex: INC opened today 06/18/2025 -->12:40 and this will be as INC Opened date & time.

but ServiceNow Instance showing up like Resolved 05/30/2025 which is past date (May) but it's opened in June.

how come incident shows up like this opened time, resolved, closed time is completely mismatch when we check in List view and proper information is not tracking under work-notes of each incident.

what could be the behavior for this functionality of incidents?

Please help as its urgent issue....

[larralapid]

If the “Incident opened date” appears later than expected, it’s usually caused by one of the following:

---

✅ 1.

Record inserted via Script or Integration

If a script (e.g., via MID server, API, or business rule) creates an incident but delays the insert, the opened_at field reflects the actual time of commit, not the time the object was instantiated in memory.

---

✅ 2.

Time Zone Settings

The opened_at field stores values in UTC, but the user’s display time zone might shift what you see in the UI.

• Check: User Preferences → Time Zone

• Also check the System Time Zone (sys_properties → glide.sys.default.tz)

---

✅ 3.

Modified via Business Rule

A business rule or data policy might have overridden the opened_at field. Look for:

• Business Rules on incident

• Any scripted use of current.setValue('opened_at', ...)

---

✅ 4.

Delayed insert via Flow/Workflow

If the incident is created through Flow Designer or Workflow, the insert step may happen after certain conditions or waits, causing the opened_at to reflect the post-delay timestamp.

---

[reddyvenugo]

Can you help me with these points in a more descriptive way?

Record inserted via Script or Integration

Modified via Business Rule

[CharanpreetK]

In ServiceNow, showing incident opened data later than the resolved or closed date can be attributed to several specific reasons:

1. Workflow Configuration: ServiceNow workflows might have some issue if it is customized as Resolved date is auto populates when the status changes to Resolved.

2. Business Rules: Custom business rules or scripts may inadvertently alter the timestamps during incident creation or resolution, causing discrepancies.

3. Time Zone Settings: If the time zone settings for the user or the instance are not correctly configured, the script then might populate it incorrectly.

4. Data Migration Issues: If incidents were migrated from another system into ServiceNow, there may be inconsistencies in how dates were recorded or displayed.
5. Scheduled Jobs: If there are scheduled jobs or scripts that modify incident records, they may inadvertently change the timestamps.

check for any custom configurations or scripts that is handling the auto population of the resolved date. Additionally, examining the system logs for any anomalies during incident creation and resolution can provide insights into the root cause.

[Kalaiarasi A]

Was that incident created from any third-party integration?