Service Level Management

Allow SLA-Priority association

I suggest to allow some sort of relation between two ITIL compliant features that are currently isolated: [ Criticality-Impact-Priority ] and [Service-SLA], so a change on Priority could somehow affect the SLA times.

I know you can relate Criticality to Service and Service to SLA but that relation is so indirect that barely adds value. A change on the priority of a ticket is currently not affecting the time an Agent has to solve a ticket.


Submitted by

Stage: Active

Feedback Score

55 votes

Idea Details

Vote Activity (latest 20 votes)

  1. Upvoted
  2. Upvoted
  3. Upvoted
  4. Upvoted
  5. Upvoted
  6. Upvoted
  7. Upvoted
  8. Upvoted
  9. Upvoted
  10. Upvoted
  11. Upvoted
  12. Upvoted
  13. Upvoted
  14. Upvoted
  15. Upvoted
  16. Upvoted
  17. Upvoted
  18. Upvoted
  19. Upvoted
  20. Upvoted
(latest 20 votes)

Similar Ideas [ 4 ]


  1. Comment

    Type + Priority = SLA would be useful

    There is however yet another dimention that would be useful:

    Priority = Service.Criticality * Impact * User decided urgency

  2. Comment

    It would be very usefull if following examples could be supported:

    Ex 1:

    Priority 1 <-> SLA 1

    Priority 2 <-> SLA 2

    Priority 3 <-> SLA 3


    Ex 2:

    Incident & Priority 1 <-> SLA 4

    Incident & Priority 2 <-> SLA 5

    Incident & Priority 3 <-> SLA 6


    Incidents could be switched with other ticket types.

  3. Comment
    Dan Abson

    A simple implementation of this could be to use the Priority field as the 'User decided urgency' (@hans.petter.holen, above) setting. If we could assign a 'default priority' to each SLA, this default would be automatically selected when the SLA is set/changed. The user would still be able to select a different Priority, or change the Priority independently of the SLA.

  4. Comment
    Community Member

    it will be very useful if priority linked with SLA not with service.

    because priority decides How much system affected by that problem and according to problem sla decides how much time it will take to solve.

    impact -> Priority

    Priority -> SLA

  5. Comment

    Yes, this is often asked by customers and since Priority field is selected while creating new ticket, it becomes imperative to link Priority and SLA.

  6. Comment

    SLA is SLA and priority is priority. They're separate for a reason and if they needed to be linked, they wouldn't need to be separate.

    Comments on this comment

    1. Comment

      Sorry crythias, but I disagree. An SLA will typically have different First Response Time, Update time, Resolution time and MTBI, for tickets with different priority. We currently use "Impact + Urgency = Priority", and all our SLAs with customers use the Priority to set the required response/resolution times... And having this 'coded' in out Service Desk system would be great :-)

    2. Comment

      Ok, so if "SLA" was labelled "Priority", it would just work, right?

  7. Comment

    Dear all,

    a new package "EscalationPlus" that (at least partly) fits the needs expressed in this idea is available on OPAR as


    An extension to allow a) scaling of escalation times by rules based on ticket type, priority, and due date as well as b) have ticket states excluded from being counted towards solution time. Both parts can be enabled individually. NOTE: This package also installs a modified version of into Custom/Kernel/System/ to fix bug#10128.


    We use OTRS::ITSM; our "operational" ticket priority is initialized from a (newly defined) CustomerUrgency * ServiceCriticality, but may be altered by the agent after first analysis.

    More on this topic under

    Feedback welcome!

    Best wishes for 2014,


    Comments on this comment

    1. Comment

      Thank you for this module. At this moment I can only say it looks promising, as I've not installed it anywhere at this moment. Where would you like to have feedback?

Add your comment