Create ticket with default SLA

[ksbuchanan]

I want to create ALL new tickets with a default SLA (ie, Standard) for all my customers. The Agent can choose a HighPriority SLA for business critical LOB applications/incidents, but otherwise, I want ALL new tickets to be assigned an default SLA.

Currently, it will show me the list of SLAs to choose from, but I don't want the Agent to "not select" a SLA. When we create a ticket now, the default entry is "-".

How do I force a specific SLA for all tickets?

[Wolfgangf]

Hi,

create a Postmaster-Filter and fill the correspondig fields:
here is an example which should help you

101225-0001.png

[ksbuchanan]

Sorry, let me clarify.

If a ticket is created by an agent, how do I force the SLA to a specific/default SLA? Currently, it defaults to "-".

Thanks!

[kmdot]

How can you set an SLA to their service?

IE

3 Services, and each service has 2 unique SLA's, how can one force a default SLA for each service when the ticket comes in? I am thinking i need to reference the email address from with services for that email address, then set sla, but how?

cheers

[ksbuchanan]

How can you set an SLA to their service?

IE

3 Services, and each service has 2 unique SLA's, how can one force a default SLA for each service when the ticket comes in? I am thinking i need to reference the email address from with services for that email address, then set sla, but how?

cheers

I'm beginning to think that creating a default SLA is impossible! I figured out how to do it it is submitted by e-mail, but 90% of our tickets are created by a phone call to the helpdesk. OTRS is good at many things, but isn't great. The ticket search function is very unpredictable, and the ability (or inability) to create a default SLA is nothing but astounding!! I guess someone will blast me and tell me "its open source...create your own module" or some BS like that. I still like OTRS, enough that I wouldn't replace with anything else I have seen (including paid/commercial applications). I just don't understand why a default SLA is like the Abominable Snowman!

[crythias]

(the following is based upon 2.4 information, but may be applicable to 3.0)
The short answer: Set PossibleNone=>0 wherever it's requested for SLAs in each .pm you need it (AgentTicketPhone.pm and AgentTicketEmail.pm at minimum).

How did I get there?

First, for anyone else who's following along, SLAs are tied to services (many services to each SLA) and services are tied to customers, but customers are not tied to SLAs. This kinda stinks, because (if I understand the terminology properly) a customer is expecting an SLA for a specific service. ... the agreement is that the service will be performed at X level. But OTRS has the ability to provide multiple levels of agreements per service. ... The best way to work around that limitation is to create a specific SLA/Service pair which would apply to the customer.

When the Service is ajax-looked up, it is based upon the Customer <-> service mapping, and based upon the service chosen (not the customer), the SLA has an Ajax-lookup which starts with (-).

So... where is this list?
It comes from $Data{"SLAStrg"} in the .dtl files

each .dtl refers to a Modules/something.pm that calls

$Self->{LayoutObject}->BuildSelection(
Data => $Param{SLAs},
Name => 'SLAID',
SelectedID => $Param{SLAID},
PossibleNone => 1,
Sort => 'AlphanumericValue',
Translation => 0,
Max => 200,

This is called from Kernel::Output::HTML::Layout.pm
mostly, look for BuildSelection ...

Seems there's something that allows SelectedValue .. eh.. that doesn't work. I wonder where the option "">-</option> stuff is. Hmm. It's still in Layout.pm
if ($PossibleNone) {
$Output .= '<option VALUE="">-$Text{"none"}-</option>';
}


Aha! ... so, if I don't want the -, I should set PossibleNone to 0 ... and it works!

(thanks for reading the rambling!).

[jojo]

If you need such a kind of functionality please feel free to order a custom module at OTRS Inc.

[Yves]

This kinda stinks, because (if I understand the terminology properly) a customer is expecting an SLA for a specific service. ... the agreement is that the service will be performed at X level. But OTRS has the ability to provide multiple levels of agreements per service

With respect to the best practices around ITIL this behaviour is actually not incorrect.
You want to offer the same service to different customers at different service levels. Therefore it'd be necessary to not just specify the available services for customers but also the corresponding negotiated service level.

[crythias]

I'm not disagreeing with you, generally. Once the customer is selected, however, he probably should only be presented with the SLA he's been assigned/purchased. Or am I missing something else in your statement?

[Yves]

Hi,

I think this needs an example.

Let's imagine we've "Service A" which we're offering at the 3 SLAs "silver", "gold", "platinum".
In OTRS you now can specify "Service A" and attach all these SLAs to it. So far that's OK.

Now you've 2 customers. "Customer A" has bought "Service A" at SLA "silver" and "Customer B" has bought "Service A" at SLA "platinum".
So in OTRS you'd like to configure that tickets from "Customer A" for "Service A" should be restricted to SLA "silver". But this would only be possible by utilizing complex ACLs. An improvement would be to allow to associate not just the service to a customer but also the corresponding service level.

I understood your comment as you did not like the fact that a service could have more than a single SLA in general.

[crythias]

I understood your comment as you did not like the fact that a service could have more than a single SLA in general.

5 years ago ... but my complaint appears to have been the same thing. SLAs attached to services (generally okay as I understand a service could have multiple SLAs) but no Customer-Service-SLA assignment combo.

I think we're on the same page.

[Yves]

I encountered this issue recently as we're now implementing ITSM with OTRS 5 and found this topic via Google.
But thanks for getting back to me even after this long time!