• 1-10 of 10
  • Ziv S
    Robert Surujbhan said:

    Hi Ziv - an incident's queue ID will be accessible using:

    var queueId = inc.QueueId;

    Reference the field list here for more details!

    View original


    Perfect, this is exactly what I was looking for!

    Thank you for the help :)

  • Ziv S

    Hello Jessica,

    Thank you for your suggestion. I have opened the following idea request:


  • Ziv S

    Hey @Sebastiaan,

    I really appreciate the information you sent regarding group concat function. I tried to do a basic expression for grouping the agent/time in inbox columns; it looks like it's not possible to use an aggregate function within the group_concat function (see attachment).

    I played a bit with the Cross Tab options under the Display tab in the report editor and got to a satisfactory result. I can't find a way to add additional images, but basically the result is that per each queue, we have 2 sub-columns with # of incidents and time in box, and the agent name showing only once. I also shortened the column names to simply 'Incidents' and 'Time' which made the report a lot more compact in terms of horizontal scrolling.

    Regardless, I will have to play a bit with the group_concat function as well as report scripts which I have yet to use to see how they can be used outside of this specific scenario.

    Thank you for your your answers everyone!


  • Ziv S

    Hey Sebastiaan,

    It's a bit of a shame that there is a fixed minimum height for the reports, thanks for the clarification either way. We will be looking into the custom field/business rules option.


  • Ziv S

    Hey Suresh,

    I do not have direct access to do what you suggested but I'll bring it up with our team and test this option. I will update here with how it went.

    Thanks for the help!

  • Ziv S

    Thank you all for your responses. The initial idea was to automate the language selection, but a short intro page with a language selection question seems like a good idea.

    I still find it a bit odd that the system doesn't allow this, but oh well :)
    Edit: by 'this' I mean the initial idea

  • Ziv S
    Gursimran Singh Saini said:

    Answers to your Questions:
    - No, agents cannot receive Incidents from RR queue by clicking on Fill Inbox.
    - For RR Queues, Pull Policy has no effect.

    Improving Incident assignment time:
    - Raise SR with Oracle Support to reduce run interval of RR Utility from 15 to 5 minutes
    - Make sure agents don't keep Incidents in Unresolved Status Type. Either move to Waiting Status, or Solve them

    Just to let you know, RR assignments happen when:
    1. Incident is created. System looks for agents having space in their Inbox, then assigns the Incident.
    2. RR Utility runs. System looks for agents having space in their Inbox, then assigns the Incident from overflow Queue.
    3. Agent marks Incident as Solved. System immediately assigns Incident from overflow Queue to that Agent.

    View original

    Thank you very much sir, I'm glad you clarified these issues!

    Regarding 3 above, do you know if this applies to solving incidents from any type of queue the agent has? For example, let's assume agent has this current inbox situation, with max inbox of 5 incidents:
    (2) unresolved incidents in RR Q 1
    (1) unresolved incident in RR Q 2
    (3) unresolved incidents in Standard Q 3

    Agent resolves (1) incident from Standard Q 3 and there are unresolved and unassigned incidents in both RR Q 1 & 2. Will agent be able to receive incidents from both queues after solving the incident? Is it true that the assignment order will be by creation date (FIFO) if there are multiple unresolved/unassigned incidents in RR Q's?

    I know this is a very specific scenario, perhaps the best way would be to try and produce it and see what happens. I will understand if you do not have an exact answer for this.

    Thanks again for the help :)

  • Ziv S


    Thank you both for your replies!

    Suresh - most of our profiles did not have this setting checked, I did find a few exceptions however. I have decided to uncheck it since it doesn't serve our needs.

    Simon - we are using RR for specific categories which are considered urgent. I won't go into too much detail but we are pretty much required to send the initial reply within 24 calendar hours, but preferably as soon as possible.These incidents represent a relatively small fraction (about 5%) of "everything else" which is more routine work. The "routine" type incidents go into Standard type queues which are then assigned to agents using fill inbox.

    We could in theory convert our RR queues to Standard queues and make sure we apply a high SLA to these incidents, however as I mentioned we prefer that these incidents be handled ASAP.

    What I think we'll do next is make sure the RR incidents are not being assigned manually by anyone for a few days so we can get a good picture of how long it takes for the initial assignment and the initial response to take place. Then we will possibly apply a high SLA to the RR incidents (probably 12 hours) and see if it affects the handling time - hopefully it will.

    I will update along the way. Thanks a bunch!

  • Ziv S

    Hey Rich,

    Thank you for your fast response. What you mentioned works well for answers, but not for guides AFAIK. We disabled the Delete permissions for almost every user on the profile level for answers. With guides, the editing is done through the Guided Assistance Explorer. I do not see an option there to add or customize rules. I guess that's because it's not technically a workspace that can be customized.
    Any further input/advice will be appreciated.



  • Ziv S

    Hey Sasi,

    Thanks for the detailed reply. I tend to agree with what you said, you have put it nicely together. We are working on an Excel template where we'll be able to import the raw data and the 'separation by hour' part will be handled there. I will edit this post and share it here in case someone else is in a similar situation. Hopefully this will be possible inside OSC at some point.