Agent Desktop

Get Involved. Join the Conversation.

Topic

    Rasheed Ahamed
    Understanding SLAAnswered
    Topic posted May 25, 2019 by Rasheed AhamedGold Medal: 3,500+ Points, last edited May 25, 2019, tagged Service Console 
    86 Views, 3 Comments
    Title:
    Understanding SLA
    Summary:
    Strange Behaviors, Problems, Solutions
    Content:

    I understand that there are lot of myths about assigning SLA. Recently I was experimenting SLA assignment to the Incidents. Based on which I have few queries.
    1.Though I have manually assigned SLAs to the Organizations, when I create Incidents for that Org, those SLA instances are not being set/instantiated. Lately i understood that I have to write Incident Rule to assign the SLA instance like [IF Org.OrgName = ABC then Apply Gold SLA (Create Instance if one does not exist)] Then it worked. Unfortunately what if I have thousands of Organizations or more than that? how to handle them in the Rule?

    2.For such huge number of Org records, if I'm doing a Data Import with SLA field included and the import is successful but the Incidents created for that Organization doesn't have that SLA instance, there is no meaning in importing. Why such behavior?

    3.I understand that even the Org records count is huge the SLAs are going to be at a a minimum level. So I have written a Incident rule like IF Org.OrgName matches regular expression OrgName1|OrgName2|OrgName3 THEN  Apply SLA instance. Is this the correct way to apply SLA for Incidents created for any given Org at once?

    4. I created an Incident which passed through the above rule and I confirmed it through Rule Log but still the SLA instance is not applied in the Incident. What could be the reason. PFA the screenshot.

    Thanks,
    Rasheed

    Image:

    Best Comment

    Sebastiaan Draaisma

    Hi Rasheed.

    If you have around 3352404 orgs that will work with 10 unique SLAs then it is from an admin point of view impossible to assign these by hand. Instead you will have to look at an identifier and work with that to assign the SLA either on incident level or org level.

    Based on the road you want to walk, an identiefer when working with techmail (email) could be:

    • something in the email header such as email domain
    • something in the thread building nr in email footer/signature etc

    When receiving incidents through the customer portal (CP) you could use:

    • A URL parameter that checks the org and writes this into a session, the session could then be used in a CPM where you write criteria in PHP to assign an SLA

    When working with that many orgs you need to work with an identifier to automate things.
    So check for something that you could use to tell the system when to use a certain SLA.

    If domain names are the same, you will need to see if they have the building nr in their email signature (or have your client make this a mandatory requirement for their employees), this way you can use a regex on the message thread.

    If you have a list of all available orgs then you could create an API solution that you just use once to set the SLA for each org, just to initialize your implementation. This could only be an option if you know the buildings on forehand. Such a solution could be done through SOAP & PHP.

    While I was unable to find documentation regarding the amount of orgs one could have, I did find info relating to the amount of contacts per org. So there may be performing issues when having this many orgs. Before setting up an advanced SLA system, it may be wise to raise an SR with Oracle to see if this amount of orgs could couse performance issues. That way your client may choose a different aproach.

    Comment

     

    • Sebastiaan Draaisma

      Hi Rasheed.

      I currently use Org SLAs only to control kb visibility through ANS_PRV_ENABLED so I can't comment on response times for orgs but your general idea of how SLAs work is correct.

      An organization, when assigned to a contact will automatically become the parent of that contact, just like a contact will become the parent of an incident when assging to an incident. Deleteing a contact will delete all incidents that contact has. Deleting an org will delete all contacts and all incidents.

      With SLAs it's slightly different. When an SLA is assigned to an org, all contacts tied to this org will get the SLA assigned to them giving each contact to that org the right access level for the KB. When creating different SLAs with different response times based on product, queue etc, this would have to be done through a BR where you correctly sated you will need to create an instance. This will make that incident receive the correct SLA. This is desired as the SLA for the org or contact could have the default resonse requirements from which you want to deviate to have a different response time. So it depends a litle on how you want things to run.

      I usually work with different SLAs (based on queue or prod) and create an instance for these incidents through a BR so the incident receives the correct rel_due date. I only use org SLA to control which answers should be visible in the KB.

      Say, you have 1000 orgs, then the questions would be:

      1. Does each org need to see unique KB content for their org only? If yes, you would need to create a unique access level and SLA
      2. Does each org has it's own unique set of response requirements (holidays, workdays & hours) or can they be shared? If they can be shared you do not need to create 1000 SLAs. Your holidays, workdays & hours may be the same for every org you work with. In that case you only need 1 SLA that you assign to incidents.
      3. Do you need to have different response times for different types of incidents? If yes, you need to create unique SLAs for this and assign them through business rules based on your criteria
      • Rasheed Ahamed

        Hi Sebastiaan,
        Thanks for taking time and writing such a detailed comment sir. Appreciate it. Currently Access Level is something which haven't came into picture. For some reason the client's business architecture is in such a way that they have to consider every building in which their services has been provided/installed as a separate Organization. So the number of Organizations that will be created inside Service Cloud will be huge (approx 3352404). The total no.of SLAs is approximately 10. So the current ask is that SLAs has to be applied at Org Level which means Incidents created for that Org should have the same SLA instance as per the Org. How to write Incident rule to apply SLA instance for this many number of Organizations. As I mentioned in my point #3 taking up Org.Name in the IF condition doesn't seem to be a right approach for me. Any inputs from you will help me paint a clear picture.
        Thanks,
        Rasheed

    • Sebastiaan Draaisma

      Hi Rasheed.

      If you have around 3352404 orgs that will work with 10 unique SLAs then it is from an admin point of view impossible to assign these by hand. Instead you will have to look at an identifier and work with that to assign the SLA either on incident level or org level.

      Based on the road you want to walk, an identiefer when working with techmail (email) could be:

      • something in the email header such as email domain
      • something in the thread building nr in email footer/signature etc

      When receiving incidents through the customer portal (CP) you could use:

      • A URL parameter that checks the org and writes this into a session, the session could then be used in a CPM where you write criteria in PHP to assign an SLA

      When working with that many orgs you need to work with an identifier to automate things.
      So check for something that you could use to tell the system when to use a certain SLA.

      If domain names are the same, you will need to see if they have the building nr in their email signature (or have your client make this a mandatory requirement for their employees), this way you can use a regex on the message thread.

      If you have a list of all available orgs then you could create an API solution that you just use once to set the SLA for each org, just to initialize your implementation. This could only be an option if you know the buildings on forehand. Such a solution could be done through SOAP & PHP.

      While I was unable to find documentation regarding the amount of orgs one could have, I did find info relating to the amount of contacts per org. So there may be performing issues when having this many orgs. Before setting up an advanced SLA system, it may be wise to raise an SR with Oracle to see if this amount of orgs could couse performance issues. That way your client may choose a different aproach.