Customers
User information
 Loading ...
Show article in Knowledge Base

 What decides which SLA is used? Export knowledge base Export     SubscribeSubscribe      Show article info

How does the system choose which SLA to set on an issue?

This tries to spell out the rules for how SLA is set on an issue.

Note: This is a work in progress

 

 

Requirements to get SLA to work:

  • CRM module must be enabled if you want to have multiple SLAs and contracts. (Otherwise only one default SLA is usable)
  • Issue field configuration - these fields are needed or recommended in the configuration:
    • SLA - mandatory
    • Next Breach - mandatory
    • Products and Product components - If you use multiple contracts for different products(services/assets/configuration items)
    • Contract - this field is highly recommended but not mandatory
  • Default SLA - it is best to use a Default SLA that has SLA Target(s) that are in use in all/most projects. This is not required, but it is a good idea to have a default SLA that is in use for all projects.
  • SLAs should have SLA Targets that are used in the relevant project(s) (and meets criteria)
  • At least one SLA should be on a contract for the relevant user or company.

 

Read more about SLA troubleshooting here.

 

 

The logic for setting SLA uses a top-down and a bottom-up model together.

  • Top-down logic get you one or more candidate SLAs based on user/company/product/contract.
  • Bottom-up logic then checks the SLA Targets and compares their settings (Project, isActive, issue criterias) to the issue values for those candidate SLAs.

 

The top-down logic will usually result in one or more SLA candidates, but these are then checked using the Bottom-up logic to narrow it down to a SLA.

The system then chooses a SLA that has a valid SLA Target in the project. Or if it cannot find a suitable SLA, it sets the default SLA (and if no default SLA exists, no SLA will be set at all).

 

It does not matter how well the SLA matches user/company/products, if that SLA does not have any valid SLA Target for the project and issue, that SLA  will not be set.

 

 

 

Knowledge Base Images/SLA/SLA mental model.png

 

 

 

Prioritization when issue is created or changed to find candidate SLAs, is done in this order:

  1. Check if the Reporter is set as user on a valid Contract that has a valid SLA
  2. If the Company field is in use, check if the company on the issue is set as Customer on a valid Contract that has a valid SLA
  3. Check if the Reporter Company is set as customer on a valid Contract that has a valid SLA
  4. Is there a Default SLA? Note: the default SLA should be active in (all) projects to work well.
  5. If none of the above is valid, issue gets No SLA.

 

What is a valid Contract for this prioritization?

  • The Contract is set to an active Status (The status does not have the 'inactive' flag)
  • The current time is in the time interval for the contract - between the 'Starts' date and the 'Ends' date of the Contract.
  • Products: If products are involved, check the Product and/or Product component on the issue and compare to contracts.
    • issue product matches one of the contracts on the user/company: Set the SLA of this contract.
    • Issue product does not match products set on a contract on the user/issue:
      • Is there a contract for the user/issue that does not have any products? Then this is a "generic" contract that should cover "all" products - Set the SLA on this contract..
      • No contract without products? Then there are no valid contracts,  go to next prioritiztation step above.
    • Note: If a user or company has more than one active contracts, they must apply to different products/services. You cannot have duplicate contracts for the user/company with the same product.
    • If products are not used, and there are two or more matching contracts, the system chooses the newest contract to set.

 

What is a Valid SLA for this prioritization?

  • SLA is set as Active
  • SLA has valid SLA Target(s) that are used in the project in question.
  • Note that these SLA Targets should not be invalid due to other criterions on the SLA Target such as issue type/status/etc.
  • If the SLA does not have any valid/matching SLA Target on the issue/project, then the default SLA should be set if it is valid.
  • If not even the default SLA can be set, then no SLA is set.

 

 

What is a Valid SLA Target for this prioritization?

  • Target is Active
  • Target is used in the project in question
  • If the SLA Target has issue criteria set, those must match the corresponding issue fields.

 

 

 

The basic control flow for determining SLA is thus:

 

Case 1:

An Issue is created by a User (the Reporter). The User matches a Contract (also checking any matching Products (or Services/Assets/CIs.. )). The Contract has an SLA, which has one or more SLA Targets

 

 

Case 2:

An Issue  is created by a User (the Reporter) that belongs to a Company (set in the Company field). The company matches a Contract (also checking any matching Products (or Services/Assets/CIs.. )). The Contract has an SLA, which has one or more SLA Targets.

 

 

Case 3:

An Issue is created by a User (the Reporter) that belongs to a Company (the Reporter Company). The company matches a Contract (also checking any matching Products (or Services/Assets/CIs.. )). The Contract has an SLA, which has one or more SLA Targets.

 

 

Case 4:

An Issue is created by a User (the Reporter) that belongs to a Company (the Company or Reporter company fields). No matching Contract can be found, so the system sets the Default SLA, which has one or more SLA Targets

 

 

Case 5:

An Issue is created by a User (the Reporter) that belongs to a Company (the Company or Reporter company fields). No matching Contract can be found, and no default SLA exists - then the issue will have no SLA or SLA Targets at all.

 

 

Notes:

  • A user can have zero or more contracts - where the user is in the User field on the contract
  • A company can have zero or more contracts - where the company is set in the Customer field on the contract.
  • A contract can have one SLA set
  • A contract can have a user and/or a company associated with it
  • A contract can have zero or more products(services/assets/Configuration items) associated with it.
  • If an issue has the Contract field, the SLA for that issue is for that contract.
  • An SLA can have zero or more SLA Targets. (But if it has no SLA Targets it will not be set on an issue)

 

 

 

 

.


User comments
 Loading ...