Hi all, Just wondering if anyone had any insight as to the best way to identify flowed-out interactions for a particular workgroup? I have a supervisor alert that sends me an email for value changes for Interactions Flowed-Out. However, not much else I can do to determine what happened to that particular interaction. I tried running a search in Interaction Details for calls that came in (Search criteria = "Last Workgroup: 'workgroup1'") but this isn't very helpful as it shows all calls that came in. I've also tried to run both Queue Detail & Summary Reports, but there is no specific detail-level information per interaction aside from "1 Interaction Flowed-Out". Any suggestions? Thank you, QW

An interaction that "flowed out" is one that enters the queue but is neither offered nor abandoned - usually due to a transfer, voicemail, etc. I'd start with the Call Log for the day in question on the active PureConnect server. Do a quick search string filter for the workgroup name, then start narrowing down by adding other string filters or exclusions for key events.

Thanks for the explanation dcurrier! When you say Call Log; are you referring to a view in ICBM? or a report? I can't find where that is to be honest.:confused:

He's talking about querying the database directly. There is nothing in ICBM or a standard report for the Call Log. All custom work.

This is one of the server trace logs that is located in the Log Path on the active CIC/PureConnect server. This generally something like E:\I3\IC\Logs\<date>\ and is called something like CallLog.ininlog

Originally posted by dcurrier;36537
This is one of the server trace logs that is located in the Log Path on the active CIC/PureConnect server. This generally something like E:\I3\IC\Logs\<date>\ and is called something like CallLog.ininlog

Ah, yes...I forgot about that log. I was thinking you meant the CallEventLog column in the calldetail view in the IC database, which stores the Call Log for each interaction. Many folks write a custom SQL query or even a custom report to pull interaction data from there for cases like this.

This column does contain the same data but it can be truncated depending on the call flow and it is harder to parse. I prefer to use the actual trace log in the ININ Log Viewer for recent questions about calls (assuming the Call Detail Viewer in IC Business Manager doesn't answer my question).

Makes sense. Have you figured out a good way to pull that data out into a report you can hand to a contact center manager? Or, do you mainly just look at single interactions as-needed?

Ahhh okay. Thank you both very much for your suggestions! I was hoping that it wouldn't come to that as my original request was coming from someone in the Business and I would not expect them to be able to access that data. I guess I will have to provide them with that assistance :)

I haven't built any reports directly using that data - rather I write specific elements to the InteractionCustomAttributes table to report against. But I do heavily use the Interaction Detail Viewer in IC Business Manager sort of like a report as a first stop for troubleshooting and in training business users how to perform basic call troubleshooting.

Oh for sure. Interaction Details is definitely my first step in troubleshooting a call. But in this scenario, it sounds like the supervisor wasn't able to see the flowed-out interaction in Interaction Details by searching the last workgroup. Since it flowed-out to somewhere, they were trying to work backwards

You might look at LogSnip to pull data from the log based on a filter (which you can create in LogViewer and save, then use with LogSnip). You can save to JSON or .ininlog format. command-line help: Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\Users\icadmin>logsnip You must specify at least one file to read (--log), and a destination for the snip (--out). Allowed options: -h [ --help ] print usage message --from arg Snip log(s) starting at specified time. Format: hh:mm:ss.mmm or YYYY-MM-dd@hh:mm:ss.mmm (use trailing Z for UTC) --to arg Snip log(s) ending at specified time. Format: hh:mm:ss.mmm or YYYY-MM-dd@hh:mm:ss.mmm (use trailing Z for UTC) --out arg File to create from merged logs - format defaults to ininlog --format arg (=ininlog) Format to use for output file: ininlog | json. Defaults to ininlog --filter arg Name of filter to use when snipping log file(s). --filter_file arg Name of xml file to load filters from. The inin_log_filters.xml file also used by ininlogviewer is used by default. --filter_list List the named filters within the default filter file, or filter file specified on the command line. --detailed_errors If set, display the full (nested) error information. --compress_data If set, tries to convert ALL data strings into single-write instances [EXPERIMENTAL!]. --log arg Log file(s) to read. Example stuff from an internal description I dug up: logsnip-w64r-5-0.exe --filter_file %UserProfile%\Documents\dsm-ininlogviewer-filters.xml --filter PolicyActionsJobDoWorkFailed --log *.ininlog --out PolicyActionsJobDoWorkFailed.json --format json The beginning of the outputted json looks like this: [ { "timestamp":"00:00:05.004_0019", "type":"E", "calllevel":0, "thread":13036, "topic":"Recorder Processing", "level":11, "file":"$Id: //eic/main_team_dp1530/products/eic/src/recorder/irserver/Action.cpp#2 $", "function":"PolicyActionsJob::do_work()", "line":54, "message":"Action failed", "attributes": { "IR_RecordingID":"e5daee13-9558-d071-88c0-ab29ba9d0001" } }, { "timestamp":"00:00:05.005_0018", "type":"E", "calllevel":0, "thread":7844, "topic":"Recorder Processing", "level":11, "file":"$Id: //eic/main_team_dp1530/products/eic/src/recorder/irserver/Action.cpp#2 $", "function":"PolicyActionsJob::do_work()", "line":54, "message":"Action failed", "attributes": { "IR_RecordingID":"e5daee13-1c22-d05e-88c0-ab29ba9d0001" } }, ... ] Now that you've got the traces you want in json form, use a scripting language to extract what you want from the json. For example, in Python you could write a script like filter-json-recordingid-context-attribute.py (reproduced below) to extract just the RecordingID context attribute from each entry in the json file: filter-json-recordingid-context-attribute.py # filter-json-recordingid-context-attribute.py # Usage: python filter-json-recordingid-context-attribute.py <json-input-file> # It is recommended to redirect output to a file. import sys import json jsonFile = sys.argv[1] j = json.loads(open(jsonFile).read()) for i in j: print i["attributes"]["IR_RecordingID"] Running this: python filter-json-recordingid-context-attribute.py PolicyActionsJobDoWorkFailed.json > failed-recordings.out ...gets you a file of just the recordingIds... Click here to expand... e5daee13-9558-d071-88c0-ab29ba9d0001 e5daee13-1c22-d05e-88c0-ab29ba9d0001 e5daee13-5d77-d07b-88c0-ab29ba9d0001 e5daee13-485c-d046-88c0-ab29ba9d0001 e4daee13-3568-d033-88c0-ab29ba9d0001 e7daee13-9954-d053-88c0-ab29ba9d0001 e6daee13-50de-d0fc-88c0-ab29ba9d0001 e7daee13-6bea-d085-88c0-ab29ba9d0001 e7daee13-76a9-d0ea-88c0-ab29ba9d0001 eadaee13-1e1b-d0ea-88c0-ab29ba9d0001 ... If you wanted something other than the RecordingID context attribute, you could do for i in j: print i["message"] or...stuff like that.