Issue with multiple Service Level Agreements on a single service with Start Response Timer

[Martyn Houghton]

I am having an issue with getting the BPM Application>Timer>Start Response Timer, when a service has multiple Service Level Agreements assigned to it. My rules are based on the Priority being set and the organisation matching, i.e. I have two organisations using the same service but have a different SLA.

Even though the organisation matches the rules in the second Service Level Agreement, the first one listed in Linked Service Level Agreement is selected rather than the second one which would match both on priority and organisation name. The BPM then fails as it has incorrectly assigned the Service Level Agreement, but is not then able to select a Service Level as the rules do not match.

It appears the Start Timer node is only taking into account the first linked service level agreement and when it is not able to find a match in the rules from that, does not then go on to evaluate the rules for the next linked service level agreement.

Cheers

Martyn

[David Hall]

Hi @Martyn Houghton

I've just been trying to replicate this scenario.. could you let me know how you have the rules configured at the service level (your first screenshot above)?

Regards,

Dave.

[James Ainsworth]

Hi @Martyn Houghton

There are two levels of rules that can be used.  One is against an SLA and these rules determine which Service Level within that SLA will be used.  These are displayed in your second and third screenshot.  The other rules are against the service which will determine which SLA to use.  On your Argonaut Service you have two SLAs.  The Manage Rules option on the Service form is how you determine which SLA is selected.  If you have not specified any rules for the SLAs on the service it will always take the first one in the list.

Regards,

James

[Martyn Houghton]

@David Hall @James Ainsworth

Had not realised that you had to add a rule at the Service Level to select the Service Level Agreement first. I had added the organisation condition in the Service Level Agreement rules, not the Service.

Now I added rules to select the Service Level Agreement into the Service, it is now selecting the correct Agreement and Level as required.

 

I am presuming that I would no longer required the organisation condition at the Agreement level rules.

Cheers

Martyn

[James Ainsworth]

That's great news Martyn that this is now working for you.  Difficult to say if that last bit is not required.  I wouldn't want to suggest without knowing your SLA / Service Level setup.  General rule is that if you have more than on Service Level Agreement you will need a rule otherwise the first is always taken, and the same for the Service Levels, if you have more than one service level you will need one or more rules to select the correct service level. 

Regards,

James

[Martyn Houghton]

@James Ainsworth

We have now got this working by adding the rules into each service, but thinking about this a bit wider would it not make sense to link the subscription of a service by an object (i.e. organisation) to include the Service Level Agreement it relates to. I.e, your subscription to access the service would determine what service level yo are entitled to on it, that way removing the need to rules to be manually set.

Cheers

Martyn

[James Ainsworth]

@Martyn Houghton

That might possibly be an option to consider.  One of the scenarios that we did consider is that one organization may have more than one SLA for a service, particularly when the organization is spread across different sites or countries.  What I didn't want to do was create too many different places that one would have to go to set up the SLAs.  Maybe there can be some defaults provided using the subscriptions.

James