User information
 Loading ...
Show article in Knowledge Base

 Problems setting up SLA?  ‑ SLA Troubleshooting Export knowledge base Export     SubscribeSubscribe      Show article info

You have configured the SLA settings but the issues does not get the SLA when created. What to do?


Note 1: Changes to SLA's does not affect older issues. Only issues created after the settings was changed will be affected.


Note 2: This article refers to Contracts and Products. These are available when using certain modules in VisionFlow as follows:

  • Contracts: The CRM module is needed.
  • Products:  The CMDB module is needed. 

An administrator can check General > Settings > Modules to see what modules are available in the account.


Note 2b. The terminology in this article refers to Contracts(Agreements) and Products(Services/Assets/Configuration items), but these items can have alternate names via the terminology function.



For the logic of how the system chooses which SLA is set on an issue, read this article:

What decides which SLA is used



Questions for troubleshooting: 

1. Does the Project have the fields "SLA" and "Next Breach"? These are needed for this to work.

  • Edit the Issue field configuration (IFC) that is used in the project, and add these issue fields.
  • The Contract field is also recommended to have in the IFC if you're working with SLAs, but not mandatory.



2. SLAs:

  • Is at least one SLA created? 
  • Is the SLA active? 
  • Does it have any SLA Targets?
  • Does it have SLA Targets that are used in the project you're interested in?
  • Does it have SLA Targets that are valid for the issue? Meaning that the criteria matches the fields on the issue, such as issue type/status/priority etc.
  • Does it have the right order number? The system checks the SLA's with lowest numbers first.
  • Does it have a Work schedule? Work schedule on SLA overrides any work schedules on SLA Targets.



3. Do you have a default SLA?

  • It is a very good idea to have a default SLA that is used in all projects and that has a SLA Target that is valid for all issues.
  • When the system cannot set a specific SLA, it will then set this default SLA.
  • If no default SLA exist, it is possible for no SLA to be set at all, if the issue does not match any contracts..



4. SLA Targets:

  • Is at least one SLA Target created?
  • Is the SLA Target active?
  • Is it used in the project? Check the "Projects and Escalations" tab.
  • Is it connected to a SLA?
  • Does it have a Work Schedule? Note that the Work schedule on the SLA overrides the one on SLA Targets.
  • Is the "Breaches when"/Breach type correct?  There are several types that work differently.
    • Time in start/running statuses: Are all statuses checked in one column(Start/running, Pause or Stop) of that list, or can the issue get to a status that is not tracked at all?
    • Does the issue have the fields required for the breach type? For example, having a breach type X hours before Start date or Due date, will not work if you don't have Start date and/or Due date fields on the issue.
  • Criterias - does these fields match the issue (for example Status, type, priority, severity et.c)? Even if you have determined what SLA should be used, it will not be set if none of its SLA Targets match the created issue.
  • Projects - are the Target set as used in the project in question? If the Target is not used in that project, that SLA may not be set at all.
  • Escalations - make sure they are triggered in the future. For example, if you have an escalation that triggers 4 hours before Start date, and you create an issue with a Start date of "right now". The escalation should have been 4 hours ago then, so that issue will not escalate at all.




5. Is there at least one contract that connects the user/company with the SLA?

  • Is the contract active?
  • Is the current time between the Start and End times of the contract?
  • Does the contract have the User field set (Customer User is a better name)?  
    • If so, is this user the same as the reporter of the issue? Yes-> SLA on contract is used, if products match.
  • Does the contract have the Customer (Customer Company is a better name) set to the Company or Reporter company of the issue? 
    • If the Company field is used on the project, that will be checked before the Reporter Company. 
  • If the contract has products set, is one of them set on the issue?
  • If the contract does not have any product, but there are no matching products on any other contracts for the user/company -> Use the SLA on the contract (this is called a "generic contract" that is used for all products that are not set on a contract)



6. Issue fields:

  • Are the user creating or editing the issue allowed edit access to the relevant fields? For example, if a user cannot set reporter, company or product fields, that may affect what Contract/SLA can be set.
  • Product/ Product component: Do the setting in the issue field configuration (IFC) allow for the contract related products/config items to be set?  If this field is limited to a certain CI type or a subtree of the whole list, it may hinder you from getting correct SLA.
  • Company field (not Reporter Company) can also be limited to a certain company type by the field setting in the IFC.
  • Note that you can manually set the Contract field (from a list of matching contracts) to choose the SLA, overriding the default selection.
  • If an issue field is set to some unexpected value after saving the issue, and this prevents the correct SLA from being set: Check if there is any issue rule, issue alert, processing rule or similar that automatically updates the issue field.




Troubleshooting chart below for when you create a new issue and an SLA is assigned..



Knowledge Base Images/SLA/SLA Quick Chart 1.png

User comments
 Loading ...