Wednesday, October 20, 2010

Efficient Agent Inbox Processing

In the IC Webclient, functionality is available called the Agent Inbox, formerly known as the Universal Agent Inbox (AUI).

A typical proces involving the Agent Inbox is the processing of complex customer questions that have been escalated by callcenter.

The Agent Inbox basically is a list of items to be processed. The items can be workflow Items, Activities, Emails, Service Tickets, Service Processes, etcetera.

The list is determined using a search on the database. It thus isn't an actual 'inbox' (where items are placed in a box), but a search result page.

When working on the agent inbox, you first select the parameters on which you want to search the system for the items. Users can be helped by Fast Search options, which are defined by the system administrator or the Callcenter Manager. A typical Fast Search option would be 'Open Items assigned to My Group'.

After the items are determined, the agent can process the open items.

PRO's of the agent inbox:

Dynamic inbox definition
Because you can set the search parameters you can define the inboxes so that one item can be in several boxes at the same time. For instance, an open service ticket can be in the Open Items box, as well as in the unfinished items box, where the Open Items contains only the Open items, where the unfinished items box also contains the items with status ‘In Progress’.

Single point of entry for different types of items that need attention
You will have Workflow Items, Contacts and Service Requests all in the same place.

Immediate Customer Context
When you choose to edit the item, the attached businesspartner (customer) is automatically ‘confirmed’ This means that you have all relevant information at you fingertips immediately without having to search for the data

Multiple User
Multiple users can work on the same inbox without running into locked items.

Search based on the Organisational Model
When retrieving the data from the system, you can use 'Items assigned to My Group', which retrieves all items assigned to any of the organisational groups the agent belongs to.

The Agent Inbox can prioritize based on Due Date. If you implement so that items with a higher priority or with a certain classification have an earlier Due Date, the Agent Inbox can give them priority.

Automatic Next Item Determination
You can have the Inbox determine the next available (highest priority) item automatically.

CON's of the Agent Inbox

The agent inbox does not automatically refresh
When the agent has processed an item it would be helpfull if this item would automatically be removed from the inbox. In some cases, this does not happen.
Especially if the item would be assigned to another organisational unit or if the item's status has changed, but is not closed yet.

Loading all items can take a while as technically it launches a search on the system
Depending on the size of the database, a search can take a while. You can set the maximum number of hits though, so it won't look for all of the thousand open tasks ;-). Standard number is 50, which should be sufficient.

No Automatic 'next-item-determination'. 
The screen does not automatically determine the next item to be processed, but there is button with this functionality.
No automatic return to the Inbox
When finishing an InboxItem, the system will not automatically return to the inbox, but to the search screen.

So, what to do now?
Of course, this blog would be useless if it would not give you an answer to the CON's.

The agent inbox does not automatically refresh
To tackle this issue, you can implement a refresh in the do_prepare_output.
You might expect longer runtimes as the system retrieves the data from the database every time, but in practice the search time is ok, as all info is already buffered.

  DATA: lv_index TYPE int4,
        lr_node TYPE crmt_bsp_treetable_node,
        lr_mixed_ent     TYPE REF TO   cl_bsp_wd_mixed_node,
        lr_item TYPE REF TO cl_crm_aui_entity.

  CALL METHOD super->do_prepare_output
      iv_first_time = iv_first_time.

* We want to retrieve the current data EVERY time the screen is opened, 
* to avoid showing lines that have already been processed.

  DATA: lr_controller TYPE REF TO cl_iccmp_in_bspwdcomponen_impl,
        lr_context TYPE REF TO cl_iccmp_in_bspwdcomponen_ctxt,
        lr_search TYPE REF TO cl_iccmp_in_bspwdcomponen_cn00,
        lr_collection_wrapper TYPE REF TO cl_bsp_wd_collection_wrapper,
        lr_bol_access TYPE REF TO if_bol_bo_property_access,
        lr_query_service TYPE REF TO cl_crm_aui_advquery_service,
        lr_result TYPE REF TO if_bol_bo_col.

      lr_controller ?= me->comp_controller.
      lr_context ?= lr_controller->typed_context.
      lr_search ?= lr_context->search.
      lr_collection_wrapper ?= lr_search->get_collection_wrapper( ).
      lr_bol_access = lr_collection_wrapper->get_first( ).
      lr_query_service ?= lr_bol_access.
      lr_result ?= lr_query_service->get_query_result( ).
    CATCH cx_sy_move_cast_error.
* set result to custom controller
      typed_context->items->set_collection( collection = lr_result ).
    CATCH: cx_bol_exception, cx_root.

  LOOP AT typed_context->items->node_tab INTO lr_node.
    lr_mixed_ent ?= typed_context->items->get_bo( lr_node-node_key ).
    lr_item ?= lr_mixed_ent->if_bsp_wd_ext_property_access~get_model_node( ).

  READ TABLE typed_context->items->selection_tab INTO lv_index INDEX 1.
  IF lv_index < 0. "No line selected yet.
*  if iv_first_time is not INITIAL.
    typed_context->items->refresh( ).
      CALL METHOD eh_onitemnext.
    typed_context->items->build_table( ).

Automatic Next Item Determination
This one was easy. You might have noticed that in one of the last rows of the coding above, the method 'eh_onitemnext' is called. This method determines thre next available item to be processed. Combined with the typed_context->items->build_table( ). that follows it, the table is also re-built.

No automatic return to the Inbox
In order to return to the inbox when the agent has pressed the 'end contact' button, an IDI rule can be implemented, that if the CURRENTINBOXITEM in the GDC is bound, the system should navigate to the inbox. As there is no standard attribute in the IDI concerning the CURRENTINBOXITEM from the GDC, you will have to create one as described here.
Of course, you will have to add some other coding in the fact gathering class.
You can for instance determine the processtype of the currentinboxitem (so you can make rules based on whether a serviceticket or contactlog or service order has been processed if you want to).

*get current inboxitem

      lv_string = lo_bdc->get_entity_attribute_as_string( path = '//CURRENTINBOXITEM/BTOrderHeader/PROCESS_TYPE'
                                          iv_suppress_creation = abap_true ).
      CALL METHOD me->set_fb_attr_by_id
          id    = 'INBOX_TYPE'
          value = lv_string.
    CATCH cx_root.

So basically, with a few adjustments, the inbox can be a very user-friendly and efficient tool to process the backlog of items.

If you have any other requirements concerning the agent inbox, feel free to leave a message in the comments below :-).


  1. Is there an efficient way of adding custom fields to Inbox Result table? The fields seem to be restricted to the structure of the table.

  2. Moisted,

    The inbox indeed is not a standard SAP CRM WEBUI table. There are some specific extra features (like the hierarchy view...) that might make it more difficult to enhance the table.
    I still think it should be possible though. Maybe you should look in the BSP in ICCMP_INBOX in the resultsview.

    Let me know if you really cannot figure it out and I will take a look if I can help.


  3. Thanks Pieter. I've been working on customizing the whole Inbox process (search and result) now for a few days. I will update you once I finish. I'm using BT Search customization.

    btw love your blog.

  4. Hi Pieter,

    Is there a way to stop of the refresh of all the result list, for example, if the 'Open Items' come back with a list of 50 items, then the agent process one item and goes back to the result list.

    The result list is refreshed again completely, causing a load and slowness of the system.

    Is there a way, where agent can select certain number of activities and only those gets refreshed.



  5. Dear Amna,

    I agree the inbox is slow.
    Depending on your implementation, you can also implement the following:

    This can speed up your inbox, but you must be sure all items are related directly to an organisational unit, and not just to a user or employee.

    I think performance-wise it would be preferable to only delete the processed item from the list instead of refreshing the whole inbox, but then the whole idea of the refreshing would collapse, as it is meant to refresh to see if other agents have maybe picked something up. The list should be centrally refreshed.

    I think the best way to go is to speed up the inbox as a whole. I know id did the trick for some of my customers.

    Send me your email address if you need more info.


  6. I have configured agent inbox but the when i click on the e-mail link and navigate to the next view, it alsways remains in disabled mode with any data.

  7. Which navigationobject/action did you choose for the automatic navigation to the inbox? Would be great if you could go a little into detail here.


  8. good information, I am facing one issue, when I am trying to retrieve data by using Assign to as my Org. model I did not get any result. can you give idea how to resolve this issue.