Alina Kurinna _SaaSJet_ Atlassian Partner

Hi @Kent G One more option if SLA behavior is one of the things driving the decision between one or two triage statuses. I work at SLA Time and Report for Jira app. With our app, the SLA logic doesn’t have to depend only on adding another workflow status. For example, you can configure the SLA to reset when the…

Hi @Jeremy Wood For the SLA part specifically, there are a few ways to make this setup easier to manage. I work at SaaSJet on SLA Time and Report for Jira. If the same SLA rules need to apply across several Jira or JSM projects, you can use a Multiple-Projects SLA instead of maintaining separate SLA configurations for each…

That’s a great point about SLA/SLE metrics potentially driving unnecessary customization. I think there’s an important distinction here: teams often need the metric, but that doesn’t always mean the Jira workflow itself needs another status or field just to make that metric measurable. I work at SaaSJet on SLA Time and…

One small addition to Sami’s point about SLAs: if those team-specific starting statuses also define when each team’s SLA should begin, you don’t necessarily need to make the workflow more complex just for SLA tracking. I work at SaaSJet, the team behind SLA Time and Report for Jira. The app works on top of the existing…

@Matt Smith Thanks for your comment! I think the distinction between First Response and Time to Resolution is actually the reason I structured the article this way. The point isn’t that a First Response SLA should include the fix. It shouldn’t. A response SLA measures how quickly the team acknowledges and starts working on…

Hi Simon @slucchesini ! Glad to hear that, and thanks for clarifying! These fields are supported, so I’d like to clarify a couple of things to understand why the Team field isn’t appearing in your SLA configuration. Could you please check: * Is the Team field added to the issue screen/layout of the same project you…

Hello @slucchesini SLA Time and Report for Jira could cover most of this use case. You can configure SLA Start/Stop conditions based on the Team field value, so, for example, one SLA can track only the time when Team 1 is responsible for the ticket. You can also configure different SLA goals based on the team if needed.…

Hey @Gunjan Kumar Really clean setup! I like that you’re treating onboarding as a shared workflow between HR, IT, and Admin rather than a single HR process.A couple of parts stood out where the setup could potentially be simplified further: 1. External intake without Google Forms + webhooks Since you’re currently using…

Hey @AGASTYA SHARMA I think it really depends on how different the departments are in terms of their processes and governance. If IT, HR, Finance, and Facilities follow relatively similar workflows, a single JSM project can be easier to maintain. You can separate the work using request types, request type groups, and…

@Mia Tamm _Simpleasyty_ Thanks a lot! That’s exactly what we aimed to show, if an agent has to stop and ask "which SLA applies here?", the setup isn't working as it should( Removing that manual guesswork makes a huge difference in daily operations. Appreciate the kind words!

Hi @Priyadarshini R , It really comes down to what specific insights you're trying to get out of this report. Are you looking for high-level metrics like overall SLA success rate and trends over time, or do you need a breakdown by assignee, priority, or request type? Also, do you need item-level details like elapsed and…

Thanks for the extra details, that actually makes things a lot clearer First, I should fix one thing I said earlier. The breached() function only evaluates the latest SLA cycle, not past ones. So in your scenario with Cycle 1 breached and Cycle 2 not breached, breached() won't pick up that issue. Only ever Breached() would…

Hi @David Quiram The native workaround suggested above can work, but it does require an additional Reset status and automation transitions each time an update is added. Another option is to use an SLA app that supports resetting the same timer based on a comment. For example, in SLA Time and Report, which my team…

Hi @piyushgupta For the general ticket metrics you listed, such as assigned, closed, reopened, and pending ticket counts, Jira’s native filters and dashboard gadgets can cover part of the requirement. For the SLA-related part, many of these views are also available directly in SLA Time and Report. For example, you can…

Hi @Steve White , One detail worth checking is what `breached()` represents in this case. The function returns work items whose most recent SLA cycle missed its goal. If the SLA can start again, an item may have a previously breached cycle while its current cycle still appears to be within the target. The board may add…

Hey @TomodachiLifeROM This is a really interesting use case. I think Jira could actually work very well for what you are trying to build, because you can configure the whole content process in one place. I previously worked in the gaming industry, and we also used Jira, although in a very basic way. Looking back, I can see…

Hi @Kevin Vancrutsen Native JSM automation can work well if you only need to send an email after a deadline is missed. However, because your deadlines depend on both status and priority, you may find it easier to manage with SLA Time and Report for Jira. My team develops this app, so I wanted to mention it as an additional…

Hi @Debbie Crum As mentioned in the previous comments, a Time In Status solution could be a good fit for this case. My team, SaaSJet, developed Time in Status for Jira, which helps you see exactly how long an issue spends in each workflow status. For example, you could separate working time statuses, such as In Progress,…

Hi @Xcon Frontier Support As Mikael mentioned, you can normally manage an SLA calendar from Space settings → Request management → SLAs, using the calendar icon in the upper-right corner. If you do not see the SLAs section, I would also check whether you have the Jira Service Management agent role and the required role in…

Hi @SlideShare Downloader The suggestions above about separate request types, queues, and automation make sense. I’d also add one more point from the SLA tracking side. If some requests stay in a waiting status too long and agents miss follow-ups after applicants send new documents, it may help to track this as a separate…

Hi @Sidney Rocha By nature, JSM SLAs are mostly designed for the agent side, so displaying the SLA and remaining response/resolution time directly in the customer request form can be limited. If you are open to Atlassian Marketplace apps, I would recommend SLA Time and Report for Jira, which my team develops. With the app,…

Hi @Shamim Ayub For high-velocity teams, I’d avoid sending every SLA warning to everyone. It usually creates noise very quickly. A better pattern is to separate SLA notifications by urgency and audience: * early warning to the assignee or responsible team * near-breach alert to a lead or manager * escalation only when the…

Hi @Laura Jiménez Goicoechea , Based on what you described, I would first check when the Tipo field is populated for the issue. If your SLA goal depends on Tipo, but this field is filled later by automation, the issue may not match the SLA goal at the moment when the SLA is expected to start. That can create a confusing…

Hi @Meital I think your `Infra Task` approach can work, but I’d treat it more as a workaround than a long-term best practice. The main issue is that it keeps Infrastructure intake spread across multiple product projects. That usually means more admin overhead, less control, and more chances for the process to get messy…

Hi @KC Wong From your test, this does not look like a configuration mistake. Jira Service Management does allow you to create an SLA by entering a new name or choosing an existing one, so your expectation is reasonable. If the UI offers to reuse "Renewal SLA", it is fair to assume that the field should behave consistently…

Hi @Damian Kowalewski If the goal is only to display a static Due Date in the native request details view, the out-of-the-box options are limited. But in practice, I’d look at this a bit differently: if the date matters because your team needs to monitor deadlines and react before something is late, then it is often more…

Hi @Vaclav Pechr , I don’t think native JSM Cloud will handle this the way you need. The main issue is that you are not just trying to filter tickets by team — you want to measure how much time L1 and L2 each spent on the same ticket while the workflow status stays the same and only the Responsible team field changes. That…

Hi @Evaldas Masiulis, As already answered above, unfortunately, this isn’t possible directly right now. However, this is actually one of the reasons we built SLA Time and Report for Jira – to help teams go beyond the limitations of native SLA reporting. If your main goal is to build more flexible SLA reports, you might…

Hi @Babar Brohi, Yes, this is definitely possible, and many teams get great results with Jira workflow automation when they start with a few practical rules instead of trying to automate everything at once. A good approach is to focus on 3 areas first: - ticket transitions for repetitive workflow steps - smart…

Hi @Mar ! Unfortunately, there is no direct native JQL for “Time to resolution is empty / not started yet”. In practice, teams usually work around this by: filtering by statuses that come before the SLA start condition, or setting a label / custom field with automation once they detect that the SLA has not started If you…