Understanding CRM Worklists
This section discusses:
Worklist characteristics.
Transaction types.
Worklist operations and transaction integration.
Worklist folders.
Worklists and queues.
Worklist feeds.
At its most basic level, a worklist functions similar to an email inbox that stores its contents in the PeopleSoft database. Various user actions trigger notifications that users access through their worklists. Beyond the basic inbox function, however, worklists offer extended integration with PeopleSoft CRM transactions, including the ability to manage assignments from a single work queue, store comments for individual worklist entries, and easily navigate between worklist entries and their underlying transactions.
Individual worklists are automatically generated for user IDs that are created in the CRM system. Users can also be members of group worklists that you define. Self-service users have their own user IDs and, from a system architecture perspective, have worklists. However, from a business perspective, self-service users should not have worklists, and you can enforce this by denying them security access to the My Worklist page.
On the My Worklist page, users can choose whether to view entries on their personal worklists or on other person's worklists that have been delegated to them. They may also view entries on specific group worklists to which the users belong, or on all group worklists to which they belong. Managers can additionally view their employees' worklists. The relationship between managers and employees is established by the Supervisor ID field in the Worker component (RD_WORKER_2).
Group worklists are applicable only for specific business processes that are explicitly designed to send notifications to the group worklist, including business processes in PeopleSoft Multichannel Applications, Support, HelpDesk, HelpDesk for Human Resources, and Integrated Field Service.
In the call center applications (PeopleSoft Support, HelpDesk, and HelpDesk for Human Resources) and in PeopleSoft Integrated FieldService, group worklists are associated with provider groups. Provider groups are groups of workers to whom work can be assigned. The association between a provider group and its group worklist is established in the provider group definition. Depending on the provider group definition, worklist notifications (manual and automatic) that are sent to the provider group are either sent to the group worklist or broadcast to each member's individual worklist.
Similarly, in PeopleSoft Sales you can set up sales teams to which notifications can be addressed, and then you can associate the sales team with a group worklist to which all team members have access.
Group worklists do not distinguish entries by specific group members. Instead, they are typically used as a holding area for work requests that are not yet assigned to an individual group member.
If multiple members use the group worklist simultaneously, a change from one member can override the other's. Refresh the Group Worklist page frequently to ensure that the most current information appears.
The system categorizes worklist entries according to the transactions where the entries originate. For example, an entry that originates from a service order is categorized separately from an entry that originates from a support case. Manual notifications (those that are sent from the Send Notification page) belong in a single category, regardless of the component from which the notification is sent.
On the My Worklist page, you can view all types of entries together, or you can filter entries so that you see only one type. When you view all entries together, you see only data that applies to all types of entries, including the entry type and an identifier for the underlying transaction (for example, the case ID). The transaction identifier is a link to the underlying object.
When you view a single type of entry, the worklist displays additional data that is specific to the transaction. For example, most transaction types show statuses of the underlying object (case statuses, service order statuses, and so forth).
This table lists the types of worklist entries and explains how the entries are generated. The names that are in the first column are the values that appear in the drop-down list box where you can choose which type of entry to display.
|
Worklist Name |
Functional Area |
Notification Source |
|---|---|---|
|
Application Message Error |
Integration Broker |
By running the Application Engine PT_AMM_WF (Error Notification ) at PeopleTools > Integration Broker > Service Operations Monitor > Monitoring > Error Notification. |
|
Agreement |
Agreements. |
The AAF carries out a workflow action for agreements. |
|
Business Project Task Task Routing |
Business projects. |
Business projects and business project tasks carry out an associated workflow action. |
|
Campaign Campaign Content Campaign Content Task Campaign List Campaign Task Marketing Offer |
Marketing. |
The AAF carries out a workflow action for campaigns. |
|
Change Request |
Change management. |
The AAF carries out a workflow action for change requests. |
|
Contact Us |
Contact Us self-service. |
Users submit information on the Contact Us self-service page, thereby triggering the workflow action that is associated with the selected subject and topic. |
|
Correspondence |
Correspondence requests that are submitted from any context. |
The process that delivers correspondence (based on a correspondence request) creates the worklist entries if it's so configured. |
|
Defect |
Quality defects. |
The AAF carries out a workflow action for defects. |
|
Email Alert Undelivered Emails |
Email response management system (ERMS). |
Email worklist entries are triggered by email routing and assignment. Email Alert worklist entries are triggered by the Email Alert processes. Undelivered Emails worklist entries are triggered when an outbound email is not deliverable. |
|
Lead Opportunity |
Sales. |
The AAF carries out a workflow action for leads or opportunities. |
|
Notify Notify_CC |
Various. |
Users manually create a notification on the Send Notification page. Manual notifications have both To and Cc recipients; different worklists are used accordingly. |
|
Order |
Order capture. |
Certain order-related business projects (those that are used for order maintenance) carry out workflow actions. |
|
Profile Activation Confirm Profile Registration |
Online marketing profiles. |
Marketing PeopleCode triggers notifications for profile registration and confirming activation. |
|
RMA |
Return material authorizations (RMAs). |
RMA PeopleCode carries out a workflow action. |
|
Service Order |
Service orders. |
The AAF carries out a workflow action for service orders. |
|
Solution |
Cases Service orders |
AAF action sends a notification or creates a business project to start the solution approval process. Note: Customers must configure a policy to take an action when a user changes the Solution Status. |
|
Case HelpDesk Case HelpDesk for HR Case |
Cases. |
The Active Analytics Framework (AAF) carries out a workflow action for cases. Note: Users cannot see summaries or details for a secure HR help desk case unless they belong to the provider group that is assigned to the case. |
As you review the entries in a selected worklist, you can perform certain operations, some of which affect the data in the underlying transaction. Also, certain modifications to specific transactions will affect corresponding worklist entries.
Worklist Operations
Users can perform these actions from their worklists:
Access the page where the worklist entry originates.
When a user clicks a link that is associated with a Case from the Worklist grid, the system takes the user to the Case page and enables the Next in List and Previous in List buttons on the Case toolbar. This enables users to scroll to the next case that's in the worklist. This functionality is only provided when the View By Type drop-down list box is set to one of the three case types, either Case, HelpDesk Case, or HelpDesk for Human Resources Case.
Mark the worklist entry complete or delete it.
Completed entries are not normally displayed on the worklist, but users can retrieve these entries by explicitly searching for completed entries. Deleted entries are permanently deleted from the system. For some transactions, marking the worklist entry complete causes the system to mark the underlying transaction complete as well.
Forward the worklist entry.
When you forward worklist entries, you indicate whether the entry should be deleted from your own worklist, marked as complete on your worklist, or left in its current state on your worklist. Forwarding a worklist entry never affects the underlying transaction.
Worklist entries for emails and external business processes cannot be forwarded. However, entries for email alerts and undelivered emails can be forwarded.
Reassign the entry to another group or personal worklist.
This option is available only for cases, service orders, and emails. Reassigning these types of worklist entries always reassigns the underlying transaction.
Accept the worklist entry (specific to ERMS worklist entries in group worklists).
When a user accepts an email worklist entry from a group worklist, both the worklist entry and the underlying email is assigned to that user.
Move personal worklist entries to personal folders or from a personal folder to the inbox.
Important! You cannot reassign or accept a worklist item if the View by Type field value is All. You must select a specific transaction type, for example, Case worklist or ERMS worklist, to be able to take these actions.
Transaction and Worklist Integration
Worklist entries for cases, service orders, and emails integrate closely with their underlying transactions. The following table summarizes the integration between worklist entries and their underlying transactions.
|
Conditions |
Case |
Service Order |
|
|---|---|---|---|
|
Worklist entry is marked complete. Is the underlying transaction updated? |
No |
No |
Not applicable; you can't mark the worklist entry complete until the underlying email is completed. |
|
Worklist entry is reassigned. Is the underlying transaction reassigned? |
Yes |
Yes |
Yes |
|
Transaction is marked complete. Is the worklist entry updated? |
Yes The CRM system delivers AAF policies that perform the update automatically and they need to be activated. |
No |
Yes |
|
Transaction is reassigned. Are corresponding worklist entries reassigned? |
Yes |
No |
Yes |
The case, service order, and email worklist updates are performed through AAF; emails are updated using ERMS-specific processing.
Users can organize the entries on their worklists using folders. Five standard folders are available; users can additionally create their own personal folders. Personal folders are used only for entries from a user's individual worklist, not for items from group worklists or from the worklists of a user's direct reports. Clicking a folder name displays the contents of that folder. A yellow highlight indicates the currently selected folder.
These are the standard folders:
The Inbox contains all items on the user's individual worklist that haven't been moved to a custom folder.
The Group Worklists folder contains all entries from all group worklists to which the user belongs.
This folder appears only if the user belongs to at least one group worklist.
When viewing the Group Worklists folder, users have access to a drop-down list box for selecting a specific group worklist and filtering the worklist entries accordingly.
The Direct Reports folder contains all entries from the individual worklists of the current user's direct reports.
This folder appears only if the user has direct reports.
When viewing the Direct Reports folder, users have access to a drop-down list box for selecting a specific employee and filtering the worklist entries accordingly.
The Delegated folder contains entries from any worklists that have been delegated to that user. Delegation of a user's worklist are defined on the Worklist Options page.
The All folder shows all worklist items in the user's personal folders, including the inbox.
It does not include items from the Group Worklist or Direct Report folders.
Users can create, rename, and delete personal folders at will. However, if a user attempts to delete a folder that is not empty, an error message tells the user to move the folder contents elsewhere (to another personal folder or to the inbox) first.
Note: The Inbox, All, Direct Reports, Delegated, and Group Worklists folders cannot be deleted or renamed
The toolbar on the My Worklist page includes a button that a user clicks to display the number of items in each folder. The folder count appears in parentheses next to the folder name. The system, however, does not provide folder counts for the Group Worklists, Delegated, or Direct Report folders. For performance reasons, the worklist does not update folder counts continuously.
By default, the system hides folder counts when the page first appears. After they are displayed, however, they remain visible as long as the user remains on the page. To hide folder counts, users must navigate to the My Worklist page again.
Important! Folder counts are only as current as the most recent time that the user clicked either the Folder Counts toolbar button or the Refresh toolbar button.
If you license PeopleSoft Multichannel Communications, which provides ERMS and chat capabilities, worklists provide additional application-specific functionality.
Queues
Queues are a variation on worklists that are used by PeopleSoft Multichannel Communications. Unlike worklists, which require users to pull work assignments from the list, queues push assignments to users using the MultiChannel Console. The PeopleTools Multichannel Framework (MCF) manages work requests that are sent to queues, scanning all agents who are logged on to a queue, and routing work only to agents whose skill level is appropriate and whose current multichannel activities (open email and chat sessions) fall below a specified threshold.
Queues are required if you use the chat capabilities of PeopleSoft Multichannel Communications; queues are optional when you use ERMS.
PeopleTools provides components to set up queues and the agents who belong to them, but you can also use PeopleSoft CRM group worklists to automatically create queues and agents. A setting on the group worklist definition tells the system that the worklist is to be considered a queue. This setting causes the system to create a queue definition and to create agent definitions for each member of the group worklist. Required queue and agent fields are set based on system defaults that you specify, and the Group Worklist page provides links to the full-featured Queue and Agent components so that you can refine the automatically generated queue and agent definitions.
ERMS Transactions
Three types of ERMS worklist entries are available:
True ERMS worklist entries represent email assignments.
When this type of entry appears on a worklist, the user or users who can access the worklist are responsible for accepting and working on that email, closing it, and removing it from the worklist. Reassigning an ERMS worklist entry to another worklist changes the assignment information that is on the underlying email. Additionally, if a user accesses an unassigned email from a group worklist that is configured for automatic acceptance, the email is automatically assigned to that user.
Email alerts.
An email alert entry notifies the recipient that an email is not closed within the warning and final notification time periods that are associated with the email's mailbox or current group worklist. These worklist entries are simply notifications with information about the specific time when the notification is sent.
To differentiate email alert entries, the worklist grid displays a single exclamation point icon for warning notifications and a double exclamation point icon for final notifications.
Because of the close relationship between true ERMS worklist entries and the underlying email, working with ERMS worklist entries is somewhat different from working with other types of entries:
An additional action, accepting selected worklist entries, is available for ERMS entries (that is, inbound emails) in group worklists.
When a user accepts an ERMS entry, the system automatically moves the worklist entry from the group worklist to the user's individual worklist. At the same time, the system assigns the underlying email to the user.
Even when an email is moved from a group worklist to an individual worklist, the system keeps track of the group worklist from which it came.
The system uses this information to send email alerts to the group worklist if applicable.
Certain privileged users (the group worklist owner and the owner of the email's group mailbox) are permitted to take ownership of any email that is already assigned to another individual.
These users can take ownership of any email that is assigned to a member of the same group.
You can route an ERMS entry to a group worklist or a personal worklist (after a group worklist is specified).
When an ERMS entry is reassigned, the system updates the email's routing history.
You cannot mark the ERMS worklist entry complete unless the underlying email has a status of closed.
See PeopleTools: MultiChannel Framework
Users with appropriate access can publish their worklist as a feed. This will let them access their worklist entries from a Web browser. PeopleTools delivers feed architecture using Atom, and PeopleSoft CRM delivers a My Worklist data source and associated feed.
Users with the role of Feed Administrator can publish their worklist as a feed. Once a feed has been published, it can be accessed as a feed using a link on the My Worklist page.
See Also
PeopleTools: Feed Publishing Framework, “Feed Publishing Framework Overview”