CSM - Jira integration - SLA CALCULATION

[mdshahvez11]

Hello Everyone,

I'm currently working on the Jira migration and need some guidance regarding Jira to ServiceNow data migration, specifically around SLA calculations.

I want to understand which date/time fields we need to extract from Jira so that we can map them appropriately in ServiceNow Task SLA definitions and determine whether an SLA has been breached.

So far, I have the following Jira fields:

Ticket Created

Resolved

Waiting for Customer

Using these, I have to calculate:

Response Time = Waiting for Customer – Created

Resolution Time = Resolved – Created

And I need help with:

1. Which fields in the Task SLA (ServiceNow) do we map these Jira fields to?

2. What should be the data type of the fields I pass (e.g., full Date/Time or hh:mm:ss format)?

3. Is there any specific format transformation required before mapping these values into SLA definitions?

Your help in clarifying this will really help me set up the mapping and transformation correctly.

[larralapid]

🧩 1.

Jira to ServiceNow Task SLA Field Mapping

Jira FieldMapped To (ServiceNow Table: task_sla)Purpose

Ticket Created	start_time (via task.created_on)	SLA start baseline
Waiting for Customer	Use a custom field or state to trigger pause_time logic	Pause/resume SLA calculation
Resolved	stop_time (via task.closed_at or custom state)	SLA end or resolution checkpoint

If you’re backfilling historical data, you may need to create task_sla records manually with proper start_time, pause_time, and stop_time values.

---

🕓 2.

Recommended Data Format

Pass timestamps as ISO 8601 full datetime format:

YYYY-MM-DDTHH:mm:ssZ  (e.g., 2024-06-01T14:32:00Z)

This ensures compatibility with both GlideDateTime and database functions.

---

🔁 3.

Transformation Notes

• If you’re importing these into task records (incident, case, etc.), ensure the historical timestamps are written to custom fields or overwrite core fields (e.g., created_on, closed_at) before SLA processing runs.

• For accurate SLA recalculation, run the SLA Repair utility (System Scheduler > SLA Repair) after inserting records.

• SLAs are triggered by conditions (like state changes or custom fields), so you may need to simulate those state transitions in the record history if SLAs don’t fire automatically.

---

✅ Bonus Tip: Use Scheduled Imports

If importing from Jira via REST or MID Server, use Import Sets to stage the data and Transform Maps with scripts to adjust SLA timestamps appropriately.

Let me know if you’d like a working transform example or help with SLA definition conditions.

[mdshahvez11]

@larralapid 

Thank you for your explanation.

I'm still not fully clear about the fields and the data I’ve fetched from Jira for each record.

Based on this data, we need to create SLA definitions in ServiceNow. We'll pass the values I have from Jira, and those SLA definitions will determine whether the SLA was breached in Jira. If it was breached there, it should reflect as breached in ServiceNow as well.

The fields I currently have are:

Ticket Created (Date/Time)

Resolved (Date/Time)

Waiting for Customer (Date/Time)

Based on these fields, I need to calculate:

Response Time = Waiting for Customer – Created

Resolution Time = Resolved – Created

I believe:

Ticket Created should be mapped to Start Date/Time

Resolved should be mapped to Closed Date/Time

But I’m unsure how to handle:

Response Time

Resolution Time

Waiting for Customer

Should these be mapped to any specific fields in ServiceNow?

Also, when calculating response and resolution times using subtraction, what format should the result be in? Should it be in DateTime, or should I convert it to hh:mm:ss format?