[rt-users] How to link SLAs to customer (requestors) or groups

[Hans Vos | Drecomm]

Hi Kevin,

Thank you for your reply. I am not very happy with a solution where 
people should send e-mail to different addresses depending on which SLA 
they have. I just want to have our regular support at ... address and not 
support-bronze at ... for example. This is not very customer-friendly.

So, this means that I can live with a solution where we make a group for 
a particular company and a custom field for the SLA of that company. 
Then assign users to that group which are the people we communicate 
with. When a ticket has been created from a requestor in that group it 
must be assigned the correct SLA.

I am not really sure that the SLA plugin does exactly in RT as far as I 
can tell it only assigned the correct due date depending on the SLA. Am 
I correct in this? Does anybody have an idea how we could implement the 
assignment of SLA based on a group and a custom field for that group?

--
Kind regards,

Hans Vos

Op 27-9-2012 17:43, Kevin Falcone schreef:
> On Wed, Sep 26, 2012 at 04:49:43PM +0200, Hans Vos | Drecomm wrote:
>> We are looking into implementing RT for our organization. For this
>> to work we need to have SLA support. I found an extension for this
>> and as I understand it an SLA is assigned based on a queue. This
>> behavior is slightly confusing to me and I don't see how this would
>> work.
>>
>> SLAs are linked to customers and when an employee from company X
>> sends us an e-mail (where company X has a Bronze SLA) we would like
>> RT to assign that particular SLA to the ticket. For this to work I
>> think SLAs need to be linked to requestors or maybe groups. We then
>> link the contact for that company to the group as requestors.
> In this case, you have a Bronze queue that people email (that's how we
> do it).
>
> However, I've implemented user specific overrides by creating a User
> custom field and on ticket creation, if the user has the custom field
> set, overriding the queue default SLA value. You could do similar things by
> checking the requestor's groups for CFs rather than checking the
> Requestor for CFs.
>
> -kevin