Use Due date (or custom date field) with TtR target date

Question

Hi there,

does anyone know if I can use the Due Date or any custom date field in combination with the target date for the SLA's Time to resolution? The Due date field would update with the projected target date of the TtR and vice versa.

But as for the different working logics, especially with the pausing of the SLA, I suspect this isn't possible?

Best regards,

Harald

Dirk Ronsmans · Accepted Answer

Hi @Harald Heinz ,

Unfortunatly out of the box you cannot use any data field to calculate an SLA target. I'm not one to push apps/additional costs on to people but if you would like more flexibility you could look at a marketplace app.

One that i've used in the past is "Time to SLA" , I'm sure that will allow you to calculate a taget based on a (custom) date field.

Alina Kurinna _SaaSJet_ · Accepted Answer

Hi @Harald Heinz

You’re right in your assumption; unfortunately, this isn’t possible with Jira Service Management out of the box.

In JSM, the Time to Resolution SLA target date is calculated dynamically based on working hours, pauses, and SLA conditions. Because of that, it can’t be directly synced both ways with Due date or a custom date field. Jira also doesn’t support defining an SLA target from a date field – only from time-based goals. So your concern about different working logics and SLA pauses is absolutely valid.

That said, this exact limitation is something we ran into ourselves, and it’s why our team built it as a feature in SLA Time and Report for Jira.

How you can solve this with our app

In our app, you can use a Negotiated Date SLA type, which allows you to:

* Use Due date or any custom date field as the actual SLA target
* Treat that field as a negotiated / committed resolution deadline
* Track SLA status (met, breached, remaining time) against that date, not a fixed duration
* Keep SLA logic consistent even when working hours, pauses, or calendars are involved

In other words, instead of trying to “sync” the SLA target and a date field, you make the date field the source of truth for the SLA.

This works especially well when:

* Resolution deadlines are negotiated manually
* The Due date may change during the ticket lifecycle
* You still want proper SLA tracking, breach visibility, and reporting

If this is close to what you’re trying to achieve and you want to check whether it fits your workflow, feel free to book a short 1:1 call; we’re happy to walk through your use case and help with configuration.

Hope this helps.

Regards!