EIM 4.3 - Route to Last Agent

Unanswered Question
Aug 18th, 2010
User Badges:


I have a requirement to have emails route to the last agent that worked on them. Using integrated EIM, I can't any way to do this.

On a previous Cisco TAC case, the engineer, mentioned something about Sticky Agents, but I couldn't find any documentation on this at all.

Has anyone here had to route to the last agent before? I do have the Data Adapter license, so was thinking of maybe some funky query in a work flow pass back to ICM the original agent ID?

Thanks for your help!


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)


I can certainly do the second part.

Create a Data Access Link and a Data Usage link and do the lookup in the worklfow (I guess the customer email address is the lookup key) and deposit the results of the query into the activity table, then pass this up to ICM in a call variable and use Queue to Agent to queue the activity. You can deal with the various options of no result, agent not logged in, queue for a while and overflow to the SG etc.

Now to the first part - how to write the agent into a database. You could get it by trolling the TCD in ICM - but you know how careful you need to be there. You could also get it in an ugly way - have a Link on the EIM desktop that writes to the database the email address and the agent peripheral number, but I think they may have to enter it.

Interesting idea. I'm willing to discuss this further.



BarryMclellan72678_2 Wed, 08/18/2010 - 08:51
User Badges:

Hmmm, I was thinking (no idea how yet), when an agent responds to an email, it must have their agent ID stored in one of the local EIM tables along with the case number. (I haven't found the EIM Database Schema documented)

Then, at the start of the workflow, check an EIM table for this case number. If the case number is found, return the last most recent Agent ID associated with that case and stuff it in a call variable.

When EIM routes up to IPCC, check and see if there is an agent ID in the call variable, and attempt to route to that agent, and keep the call queued with that agent for XXXX seconds before overflowing to an EIM queue.

What do you think?



We are in agreement on part 2.

The schema for 4.3 is not published yet - I have requested it myself. But the 4.2 is published and worth checking out.

Since the PIM certainly passes down the agent ID in the DO_THIS_WITH_TASK event, it is most certainly in some EIM table, and I bet you can find it in the schema. It will be almost certainly matched on activity ID. I'm guessing you would have a few joins to do to get from the case ID to the previous agent, but maybe not.

Go to Cisco.com and download the schema doc.

If I get a little time this morning I'll have a quick look myself. It's interesting.



BarryMclellan72678_2 Wed, 08/25/2010 - 07:11
User Badges:

Well, I am getting close!

Have the cisco agent ID being passed back to a mapped call var in IPCC. Now just have to queue to the agent ID, and see how that affects reporting!

Let me know how you made out, if you are still interested, I can post what I have done so far.



What does it look like? Is it a number like 5001, 5002 etc (primary key SkillTargetID in the Agent table) or is it the agent's Peripheral Number? If it came down from ICM in the DO_THIS_WITH_TASK it will be the SkillTargetID.

For Queue to Agent implicit you need the Peripheral Number.



BarryMclellan72678_2 Wed, 08/25/2010 - 22:46
User Badges:

Hey Geoff!

I wrote a nested SQL query so that I could get the case ID, and the last user who worked on it. I then take the user who worked on it (which is an EIM index), and hit the EIM agent table to get the login name.

Since I am using integrated the login name is prefilled which matches my IPCC agent login id exactly, I can send this data back in my call variables, and use the queue to agent node.


Since I am using integrated the login name is prefilled which matches my IPCC agent login id exactly, I can send this data back in my call variables, and use the queue to agent node.

Barry, as long as you send up the agent's peripheral number (what they would use to log in to CTIOS) you will be able to use the Queue to Agent in implicit mode. The name will not work - but that is what you select in explicit mode in a Queue to Agent node.



BarryMclellan72678_2 Thu, 08/26/2010 - 12:56
User Badges:

Yup, sending up the agent login number (same that they use for CTIOS).

So far it is working great, now on to yet another work flow that isn't in the product that should be!

BarryMclellan72678_2 Thu, 08/26/2010 - 14:11
User Badges:

Sure, here is the query for my data access link.

My Data Usage Link passes in the case_id macro.

select USER_NAME
from egpl_user
where egpl_user.user_id IN
   select case when egpl_casemgmt_case.user_last_worked IS NOT NULL then
      end as New_Owner

   from egpl_casemgmt_case,
          where egpl_casemgmt_case.customer_id = egpl_casemgmt_customer.customer_id and
                    egpl_casemgmt_case.case_id = <%case_id%>

There is obviously a bit to setup in your workflow, data access links, adding new field to activity table, and all that good stuff. If you need more info, let me know.


kimv Fri, 08/27/2010 - 05:13
User Badges:
  • Cisco Employee,

Hi Barry,

It isn't actually called "Sticky Agent", its called "Preferred Agent".

The way you do it is to put a User node within the Inbound Workflow which has several options and is placed at the end of a workflow.  Of course the agent that is the Preferred (sticky) agent needs to be currently logged in.  Truthfully I haven't played around with it in my lab, but you can find it in the following document.


Hope this helps.


kimv Fri, 08/27/2010 - 06:11
User Badges:
  • Cisco Employee,

Kim Vogler

Customer Support Specialist IV

Unified Contact Center Products

[email protected]

Phone: +1 978 936 3356

Cisco Systems, Inc.

1414 Massachusetts Ave

Boxborough, MA. 01719

Cisco.com - http://www.cisco.com

Please note that my regular business hours are 8:00am to 5:00pm EDT. // If

you are contacting me in regards to a Service Request that we are working

together, and I am unavailable, please refrain from requeuing unless there

is an urgent need to speak to an engineer. If however you do need to work

with a TAC engineer urgently while I am unavailable, you may requeue this

Service Request to an available engineer by either calling the 800.553.2447

TAC Toll Free number or writing the [email protected] address and requesting it.

This email may contain confidential and privileged material for the sole use

of the intended recipient. Any review, use, distribution or disclosure by

others is strictly prohibited. If you are not the intended recipient (or

authorized to receive for the recipient), please contact the sender by reply

email and delete all copies of this message.

For corporate legal information go to:


BarryMclellan72678_2 Fri, 08/27/2010 - 08:35
User Badges:

Thanks for the attempt Kim, nice to know you guys are monitoring these thread's as well!

I'm sure by version 6, this should be all integreated


lohjintiam Wed, 09/22/2010 - 04:11
User Badges:

Isn't this fixed?

CSCtb98517 Sticky Agent functionality broken

Sticky Agent functionality broken. Emails are not being assigned back to last agent who updated the case/activity.

CIM 4.2.5, ES4, and an ET image (Engineering Test image).
ICM 7.2.6



BarryMclellan72678_2 Wed, 09/22/2010 - 05:44
User Badges:

Hi JT,

The problem is 'kind of' fixed, however their version of 'sticky agent' doesn't really work very well.

Here is the scenario - using the sticky agent.

Step 1:

Email comes in to IPCC after routing through EIM

No Agent ID is passed with the email

Agent A receives the email

Agent A sends email to customer

Customer responds

Email comes back into system, EIM see's there is an existing case and passes IPCC the agent ID for Agent A.

IPCC routes the email to the agent -- ** Perfect **

   - however EIM has now updated the customer's preferred agent id with the last agent who handled the email.

Step 2:

Email comes in to IPCC after routing through EIM

No Agent ID is passed with the email

Agent B receives the email

Agent B sends email to customer

Customer responds

Email comes back into system, EIM see's there is an existing case and passes IPCC the old agent ID from Agent A.

IPCC routes the email to the agent A  ** BAD **

    - if Agent B was swift enough to change the preferred agent id to their ID, Agent B would have taken the call.

Now, these are two simple steps,imagine if you had a customer with two different email threads at the same time working with two different agents... much like we would do if we had more than one TAC case open.

The change EIM needs to do, is route based on the last agent who was working on that specific activity.


lohjintiam Wed, 09/22/2010 - 11:10
User Badges:


Thanks for explaining!

I guess the problem lies in the initial email where no Agent ID is passed from EIM to ICM? Some might argue that (taking Step 2 as example), it should try to route to Agent A first if not available then route to Agent B and continue on with Agent B from there onwards.


BarryMclellan72678_2 Thu, 09/23/2010 - 08:09
User Badges:

The problem is, that even if you wanted to try A, then go to B, once B worked on it, the next reply for this same case from the customer would go back to A, and not B, B would not be known by the system.

partheeban1 Wed, 11/10/2010 - 04:45
User Badges:

Hi Barry,

We are running the UCCE integrated EIM 4.3.2 and we required these type of call routing. Could you please share us what are configurations need to be done for achieving this functionality.



This Discussion