Managing Email

This chapter provides an overview of email management and discusses how to:

• Access inbound email.

• Work with inbound email.

• Reply to inbound email.

Note. Throughout this chapter, the term group worklist refers to both regular group worklists and MultiChannel Framework (MCF) queues.

Understanding Email Management

This section discusses:

• Agent tasks.

• Editable information on the email workspace.

• Email sender identification.

• Email assignment and routing.

• Mailbox reset for email.

• Email classification.

• Assistance.

• Content sources.

• Solution and document search.

• Quick action buttons.

• Related transactions.

• Email replies.

• Email status tracking.

• Reply deadlines and notifications.

• System information for email messages.

Agent Tasks

Agents normally begin to work on emails after they are routed to the first group worklist.

Email Handling

When agents are ready to work on emails, they:

1. Access the email.

   Typically, agents access email from either their worklists or from the Multichannel Toolbar. In addition, email is also accessible from the Search Inbound Emails component, from the 360-degree view of the associated customer, and on interactions lists that appear in various locations.

   See Accessing Inbound Email.

2. Accept ownership of the email.

   Agents must be members of the group worklist to which emails are routed to accept those emails. Accepting ownership moves the email out of the group worklist and into the agent's individual worklist. The acceptance of an email is either automatic or agent-initiated. The method of acceptance depends on how the group worklist is defined and how the email is accessed:

   • If the agent accesses the email from the Multichannel Toolbar, acceptance occurs automatically when the agent navigates to the email.

   • If the agent accesses the email some other way (for example, through My Worklist or the email workspace) and the email is currently assigned to a group worklist that uses automatic acceptance, then acceptance occurs automatically when the agent navigates to the email.

   • If the agent accesses the email not from the Multichannel Toolbar and the email is currently assigned to a group worklist that does not use automatic acceptance, the agent must explicitly accept the email by clicking the Accept button from the email workspace or My Worklist.

   • If the email has been reassigned or rerouted to an agent's worklist directly, the acceptance happens automatically, which means the agent is now responsible for processing the email.

3. Review the email on the email workspace to become familiar with its content.

   The email workspace recommends actions that agents can take based on the category of the email. Agents can enter the value manually as they set fit. Selecting a new category for the email on the Main tab of the Email page updates the recommended actions list immediately.

   Agents can search for additional materials (such as solutions and documents) to help resolve the issue and include these materials in the email response. The system uses solutions that are added to the proposed list as the criterion to search for templates that can apply to the email response. For documents that are added to the list, they are readily available as templates that agents can select to send. Documents are defined as correspondence templates in the system.

4. Modify data as necessary.

   Although most fields are not editable, agents can make these modifications:

   • Change the email sender information if the mail reader process (RB_MAIL_READ) misidentified the sender or was not able to provide complete sender information.

   • Specify values to categorize the email.

     Categorization attributes include category, type, product group, product, mood, and priority.

   • Modify the email subject text for greater clarity.

   • Associate solutions to the email and maintain the solution status as it pertains to the email.

   • Change the email's thread association.

   • Add notes to the email.

   • Change to a different mailbox using the mailbox reset feature if the email was incorrectly sent to this mailbox.

5. Create transactions for the email.

   • Agents can create new transactions or associate an existing transaction with the email if that is the most effective way to handle the issue.

     For example, if the email reports a product support issue, the agent can create a support case and associate it with the email.

   • Agents can delete inherited transactions if they are not relevant to the current email.

     An email that the system identifies as part of a thread inherits the parent's related transactions.

   • Agents can navigate directly to related transactions to work on the sender's issue.

6. Reply to the sender.

   Agents can reply or forward the email directly from the email workspace. If there are related transactions, agents can reply from the corresponding component. Replies can be free-form text or template-based.

7. Close the email.

   Agents can update the email status on the Email page (by explicitly selecting an applicable status). If the agent is the owner of the email, replying to the email in the email workspace automatically updates the editable email status to Closed - Response and the system email status to completed. The system also updates the status of the corresponding entry in the agent's worklist to completed. If the email was opened from the Multichannel Toolbar, it is removed automatically from the task list after the agent sends a response.

   Note. By default, the system asks agents if they want to enter a note after they have sent an email response. This feature can be disabled as part of the email user preferences.

If, after accepting an email, the agent is unable to complete the email handling process, the agent can requeue the email to its previous group worklist or reassign it to another one. If the agent determines that the email does not require handling (for example, if the email is spam), the agent can end the process at any time by setting the editable email status to Closed - Canceled.

See Understanding Automated Mail Processing.

See Personalizing Email Workspace.

Email Modes

The ability to update data and perform various actions in the email workspace depends on the user who accesses it. The description of the conditional logic for specific fields is available throughout this chapter. This table summarizes the actions that are available to different users depending on whether the email is currently assigned:

Note. From the email workspace, users must accept an email before reassigning it. From My Worklist, however, users can reassign an email without first accepting it. In addition, any user can add notes to an email regardless of the state of the email or user permission.

Editable Information on the Email Workspace

After accepting ownership of an inbound email, an agent can modify certain data, including the email subject, status, sender information, and thread information.

See Email Status Tracking.

Email Subject Text

Email subject lines help users to better identify emails. However, emails often have blank or nondescriptive subjects. Consequently, agents may want to replace an inbound email's original subject with more descriptive text. You can configure the system to add a default subject to emails with blank subject fields, but the default text should be generic. If you do not set up default subjects, the default subject is <No Subject>.

Agents can edit the subject text only after accepting ownership of the email. After the new subject text is saved, the agent cannot retrieve the original subject text. Although the original data still exists in the PeopleTools email table, it is not available to users through PeopleSoft Internet Architecture.

See Defining System Settings for Email Processing.

Email Threading

An email thread consists of a beginning email (which can be an inbound or outbound email) and all of its descendants—that is, replies, responses to replies, and so on. When you look at an email that belongs to a thread, viewing emails that are dated earlier in the thread provides a history of the discussion.

Both the email workspace and the Outbound Email component include a Thread page that shows email threads in the tree view. You can review summary information about the emails, look at the content of the selected email on the Email Message area, and navigate to an email for detailed information. By associating with another email on the Recent Activities tab on the Email page, an agent can change the thread association as well.

When an agent replies to an inbound email, the system threads the reply to the inbound email. If the agent sends the reply from the context of a specific inbound email, the threading association is automatic. If the agent sends the reply from the context of a transaction (for example, a case that is associated with the inbound email), the system provides a page in which the agent explicitly identifies the inbound email.

When an agent sends an outbound email (either an ad hoc notification or an email reply), the system appends an identifier known as a context tag to the body of the email. If the customer replies to the outbound email and includes the context tag in the reply, the context tag enables the system to establish the new email's thread association. An email automatically inherits its parent's related transactions.

When an agent associates the current email to another email thread, the items that are associated with it (for example, solutions, documents, and notes) are all moved to the new thread.

The ability of the email process to correctly add new emails to a thread depends on customer actions that agents cannot control. For that reason, the system also enables agents to add emails to a thread manually. Access the Recent Activities tab on the Email page and select Emails as the activity type. Agents can select the desired outbound email either from the search result list that appears (where both inbound and outbound emails of the sender appear), or look it up from the search by clicking the Search Outbound Emails link. When selecting a new parent email, the agent selects from outbound emails. The recipient of the outbound email must match the sender of the inbound email.

Note. Changing sender information for one email does not affect the sender information for other emails in the thread. If a threaded email's sender information is inaccurate, correct the data for each email in the thread.

Email Sender Identification

This section discusses the fields that identify an email's sender and explains how these are populated.

Sender Identification Fields

These three fields on the email workspace identify the sender. These fields are located on the More tab of the Email Details group box on the Email page:

If a role is identified for the sender, you can access the sender's record by clicking the sender's link on the toolbar summary area. You can also access the company or consumer record that the sender represents if it's identified as well.

See Managing Inbound Email.

Automatic Sender Identification

The mail reader process attempts to identify the email sender automatically. To do this, it attempts to match the email's from address with an email address in the Customer Relationship Management (CRM) database. The system's ability to populate the Sender and Representing fields depends on the available information. The mail reader process functions differently under the following conditions:

• The email address is not recognized.

  Based on the mailbox-level setup, the mail reader process either associates the email with the anonymous user that is specified on the Anonymous Object page of the Installation Options component or creates a new user based on the unidentified email address.

• The email address is associated with one person, and that person has one applicable role.

  The mail reader process populates the Sender field. Additionally, if the sender role is contact, and the person is a contact for one entity (either a consumer or a company), the mail reader process populates the Representing field.

• The email address is associated with one person and that person has more than one applicable role.

  The mail reader process populates only the Sender field, and the Email page (in the More tab) displays a Role drop-down list box that the agent uses to select a role for the sender.

  This condition does not apply to internal mailboxes, which always set the sender's role to worker. For partner mailboxes, the sender role is always contact.

• The email address is associated with more than one person.

  The mail reader process populates the Sender field with the first user that it finds and enables a multiple person indicator in the email record. The indicator displays a Mark Sender as Verified button on the Main tab of the Email page to alert the agent that the sender data needs to be verified (because it may need to be changed). The agent, when satisfied with the sender data, clicks the button to turn off the multiple person indicator. When the agent clicks the button, the button label changes to Verified until the agent saves and exits the email. After that, the button no longer appears on the page. This button does not appear when the agent has updated and saved the business object information of the mail.

Manual Sender Identification

The mail reader process does not always provide all of the sender information. Agents must sometimes verify and enter accurate sender information. Only the assigned agent can modify this data.

Identifying sender information for emails of an internal mailbox is straightforward. When agents click the prompt of the Sender field, the system performs the search against workers. The sender role is worker (this information does not appear), and the sender does not represent any entity (the Representing field does not apply).

The procedure of identifying sender information for emails that belong to an external mailbox varies depending on the information that the mail reader process provides:

• If the agent must manually identify the sender, either because the mail reader process didn't identify the sender or it identified the sender incorrectly:

  When the agent enters data or clicks the prompt of the Sender field, the system performs the search that enables selection of contacts and consumers. When the agent locates a sender using the business object search, it automatically identifies the sender's role. If the role of the identified sender is contact, the search presents a list of companies and consumers that are associated with the sender so that the agent can further identify what the sender may represent. If the role is consumer, the system populates the Sender field with the selected consumer. The representing information does not apply to consumers.

  Assume that both the sender and representing values are already populated. If the agent clicks the Representing field prompt, it displays a list of companies and consumers that the sender represents as a contact. In the case where the agent clicks the Sender field prompt, the system displays a list of senders, which means the agent is essentially searching for a new sender for the email.

  Typically, agents search for the email sender, then find the entity that the sender represents if the sender role is contact. If the agent wants to change the representing value and click the prompt next to the field, the list of consumers and companies that the sender person may represent appears. In either prompt, if the agent selects a consumer from the list, this value is populated to the Sender field, and the Representing field no longer appears.

  See Understanding the Business Object Search and Quick Create Process.

  See BO Searches on Configurable Search Pages.

• If the mail reader process correctly identifies the sender, but the sender is associated with more than one role:

  An agent uses the Role drop-down list box to select a role. When the role is set, this drop-down list box no longer appears.

Identifying sender information for a partner mailbox's emails involves searching for a sender (contacts only). The search then presents a list of partner companies that are associated with the sender so that the agent can further identify what the sender may represent.

Note. Agents must provide the sender and role information if the mail reader process is unable to do so. While the role remains unknown, users cannot create related transactions (for example, new cases or leads) from the email workspace.

Customer Quick Create

If the business object search cannot return a match from the database, agents can add new business objects using the quick create functionality, which include:

• Create consumer.

• Create consumer with contact.

• Create company with contact.

Important! Only external mailboxes support quick create. Creation of workers are not supported.

See Setting Up Business Object Search and Quick Create.

Business Unit Identification

The email workspace uses the business unit that is specified in the mailbox definition as the default value when performing these operations:

• Creating transactions: when the agent creates a transaction (for example, add an order) from an email, the system creates the transaction using the same business unit that is defined in the mailbox to where the email belongs.

  In an example where the system creates a case for an inbound email routed to a group worklist that has enabled the Create Case for Every Inbound Email option, the system uses the business unit that is specified in the group worklist definition as the business unit of the case. If this default value is not available, the system accesses the mailbox definition to identify an email business unit using the setID of the case customer, who is also the email sender (for external mailbox type), or use the default business unit that is specified in the definition as the email business unit (for internal mailbox types). Using the email business unit, the system identifies the business unit to use for creating support cases (for external and partner mailbox types), as well as the business unit to use for creating helpdesk cases (for internal mailbox types).

  Note. If the setID of the email's sender or representing entity and the setID that is associated with the mailbox's business unit are not the same, the system displays an error when the agent attempts to create a transaction. The operation cannot be completed.

  See Defining Group Worklists, Defining Email Business Units.

• Searching for transactions: if the agent wants to associate the email with an existing transaction or outbound email within email workspace, the initial search is limited by the business unit.

• Creating business objects: when the agent creates a new contact or consumer through the quick create feature, the business object is created under the setID with which the mailbox's business unit is associated.

• Searching for business objects: if the agent wants to change the value of the Sender or Representing field, the search of business objects is applicable to all setIDs.

An agent can change the business unit of an email , and the change is limited to business units that belong to the same setID as the current business unit. The also value changes when the mailbox reset operation takes place, which changes the business unit to match the business unit setting of the new mailbox that the email is routed.

Email Assignment and Routing

This section discusses how emails are sent to group worklists and individual worklists and discusses how emails can be rerouted to different mailboxes. The History page of the email workspace includes a link that you click to see the email's entire routing history, including a routing method and routing reason for each reassignment.

Group and Individual Worklists

An email begins its route through the system in a group worklist. Before an agent can work on the mail, however, the agent must accept it (either explicitly or automatically). When an agent accepts the email, the system assigns it to that agent and moves it to the agent's individual worklist.

The options that are available on the email workspace to process emails change after they are accepted. Before the acceptance, things that agents can perform on emails are minimal: accepting emails or adding email notes. After the acceptance, email owners can choose to reassign them, modify certain email data, work on them and search for solutions and documents to resolve email issues, manage relationships with other CRM transactions, and respond to them or forward them to other people. Agents who belong to the same group as the email owner can reassign, reply, and forward the assigned email. However, when the email is closed by a group member, it is neither closed automatically nor removed from the worklist. This functionality applies only when the email is closed by its owner.

After an email is assigned to an agent, the email appears in an individual worklist. The system still keeps the name of the previous group worklist and uses this information to:

• Set worklist-level response deadlines.

• Identify the group worklist owner and group worklist members.

  The group worklist owner and the other group worklist members can take ownership of a email even after it is assigned to someone.

• Identify where to send an email that an agent requeues.

  Requeuing returns the email to the previous group worklist.

• Route subsequent emails in the same thread.

  If the email process identifies a new inbound email as a continuation of an existing email thread, it routes that new email to the group worklist of the most recent inbound email in the thread, if the Process customer response as new email option is selected at the system level. For example, suppose that an agent replies to inbound email A by sending outbound email B. If the customer sends inbound email C in reply to email B (and if email C contains the code that enables the unstructured email process to identify the thread), the process routes email C to the group worklist for email A.

  Suppose that the Process customer response as new email option is selected, and the inbound email is associated with a case that is currently assigned to a provider group, the email process routes the email to the group worklist of that provider group.

  If the option is not selected, the system routes the inbound email to the group worklist of the sender (an agent) of the previous outbound email.

  See Understanding Unstructured Email Routing.

Note. You may need to make the name of the process generic if the unstructured email process has been renamed or if it doesn't handle thread based email.

Routing to a Group Worklist

The email process initially routes all emails to group worklists. After that initial routing, agents have two ways to route emails to a group worklist:

• Reassign an email to a different group worklist.

  To do this, the agent clicks the Reassign button on the My Worklist page or the Reassignbutton on the email workspace toolbar. The system prompts the agent to select a routing reason code and to enter a comment explaining why the email is reassigned.

• Send an accepted email back to the previous group worklist and let it be assigned to another member in the group.

  To do this, the agent clicks the Requeue toolbar button on the email workspace.

The system keeps statistics to show what percentage of email is routed to a group worklist other than the one selected by the unstructured email process. Use this information to assess and fine-tune the unstructured routing rules.

See Reviewing Worklist Statistics for a Mailbox.

Assignment to an Individual Worklist

The system routes an email to an individual worklist when an agent accepts the email—that is, when the email is assigned.

Email is routed to an individual worklist when:

• The agent opens an email from the Multichannel toolbar.

• The email is routed directly to the agent's worklist.

  An agent can reassign the email (owned by the agent) to another agent's worklist as appropriate. Prior to selecting an agent, you must select a group worklist so that the system can base the internal response time computation on the corresponding group worklist setup. In other words, the agent selection is refined by the group that you choose in the first place.

  Emails that are routed to agents show up in their individual worklists only. Agents should access their own worklists for the complete list of emails that are assigned to them.

• The email's group worklist uses auto-acceptance, and an agent who belongs to the email's group worklist navigates to the email.

  The agent can either requeue the email to the previous group worklist, reassign it to a different group worklist or a different mailbox, but the routing history still shows that the email was previously assigned to that agent.

  Auto-acceptance of email occurs when all these conditions are met:

  • The group worklist that the email routes to supports auto-acceptance.

  • The email is not assigned to any agent and is not closed.

  • The email is opened by an agent of the group worklist to which the email is routed.

• An agent explicitly accepts the assignment.

  When the worklist does not use auto-acceptance, agents must explicitly accept email. They do this by clicking the Accept button on the toolbar of the email workspace or by clicking the Accept button on My Worklist.

• A group worklist member or the group worklist owner explicitly takes ownership of the email.

  These users can accept email even if it is already assigned to someone else. To do so, they click the Take Ownership button on the toolbar of the email workspace. This button is not visible to other users.

Routing Reasons

The system uses routing reasons to provide additional details about an email's routing history.

When the email process routes an email, it sets one of these routing reasons:

• Routed: The email is routed to a group worklist successfully. None of the other routing reasons apply.

• Bypassed: The email is routed to the mailbox's default worklist because the mailbox's automatic routing option was not selected.

• Oversized: The email is routed to the mailbox's default worklist because the system could not perform thread-based routing or content analysis on an oversized email.

  Because of the way that the system stores the content of an oversized email, the email's body text is not available for thread analysis or content analysis. The Unstructured Email routing process can still perform customer-based and context-based routing on an oversized email, but if neither of these subprocesses routes the email, the system does not perform the content analysis subprocess. It sends the email directly to the mailbox's default worklist.

• Encoding: The email is routed to the mailbox's default worklist because of errors reading the email.

When users perform certain routing actions, the system sets these routing reasons:

• Accepted: A user has accepted the email, either explicitly or because the email belongs to a worklist that uses auto-acceptance.

• Requeued: A user who accepted the email sends it back to the previous group worklist.

When users manually reassign an email to a group worklist, the drop-down list box for routing reasons includes all of the preceding values, as well as the these additional values. The business rules of the organization determine how these values are used:

• Escalated.

• Misrouted.

• Overridden.

• Reassigned.

• Other.

  When you use other, you must include a comment to describe this routing reason.

Mailbox Reset for Email

If the system assigns an email to a mailbox by mistake, agents can initiate the mailbox reset functionality to remove all the mailbox-related data from the email. The email is then reprocessed by the ERMS system. When the reset is completed, a routing history entry is logged. The email workspace resets some data (for example, existing categorization, recommended actions, suggested solutions, and assignments and statuses that are not New) of that email so that the mail reader process can process it as if it's newly fetched from the email server. This type of email has a special status, and the mail reader process doesn't get it from the mail server but from within CRM because this type of email is already stored in the database. The processing is the same for new emails and those that are reassigned to different mailboxes. As a result of a mailbox reset, email workspace recomputes the external response time for the email so that the alert notification doesn't get fired prematurely.

Important! Exercise caution before using the mailbox reset functionality. Resetting involves the removal of some email data to complete the process and the operation, when finished, cannot be reverted.

Email Classification

Classification of emails is important when it comes to providing accurate recommendation of actions to resolve emails, and suggestion of correspondence templates to use in the email response.

Types of Classification Data

An email can be classified by:

• Category: a high level classification of an email (for example, problem, inquiry, or complaint).

• Type: a sub-categorization within a category (for example, within the problem category, types can be printer, monitor, or processor).

• Product Group: a high level product categorization.

• Product: a sub-categorization within a product group.

• Mood: the email sender's general disposition (for example, upset, neutral, or happy).

• Priority: the urgency of an email.

• Language.

  The language of the email is based on the mailbox setting. After the email is accepted, the owner can update the language.

The classification data that appears on the Response page is always editable. The email owner can enter classification values as they see fit. Classification data is not required, but it helps the system to perform more effective searches on correspondence templates or recommend actions.

See Understanding Automated Mail Processing.

Classification Data Usage

Classification data is used in these areas:

• Recommending actions on the Email page based on the category selected for the email.

  You establish the relationship between categories and recommended actions to perform for categories at the mailbox level.

• Searching for correspondence templates on the Response page based on the available classification data.

Assistance

The email workspace provides a central area where agents can find ideas to resolve email issues. Before an email becomes available to the agent, it goes through a process that can return recommendations on actions. Agents can take the advice that is available on the email workspace, or reclassify the email to get new recommendations and suggestions.

There are three types of assistance: action recommendations, solution and document suggestions, and recent activities.

Action Recommendations

Emails get action recommendations based on their categories. The system displays the recommended actions that are associated with the email category, as specified in the mailbox definition. Changing the category in the email workspace updates the recommended action list.

Email workspace delivers three recommended actions:

• Respond to sender: transfers to the Response page to compose the email response.

• Compose auto acknowledgement: transfers to the Response page and applies the auto-acknowledgement correspondence template that is specified in mailbox definition.

  Note. You must specify a correspondence template in the mailbox definition to enable this auto acknowledgement action.

• Close as duplicate: cancels the email setting and updates the status to closed - duplicate.

Recent Activities

When this tab appears for the first time, it lists recent activities that pertain to the email sender (for example, cases that have been created under the sender or associated email correspondence). On this tab, the agent can:

• Create, search for different types of transactions (that are enabled to interact with ERMS), and associate them to the email.

• Search for other emails that are related to the email and associate them with it.

You establish a list of activities (transactions) that can be performed at the mailbox level, which becomes values of the Activity Type drop-down list box on the Recent Activities tab. In addition, set up the list of default activities that are retrieved every time that the email is opened. Agents can personalize the default activity list in the User Preferences page and select the type of activities that they want to see in the results grid. The user-level preference overrides the mailbox-level definition of default activities if the former is available.

When the agent replies to the email with transactions or emails selected from the list, it causes the automatic association of the selected items to that email. Among the list of enabled activities that are specified in the mailbox definition, the actual values that are available in the Activity List drop-down list box are filtered by what the sign-on agent is authorized to access. For example, if internal helpdesk agents do not have the permission to access support cases that are external-facing, they cannot create or search for support cases from the email workspace even if the activity is specified in the mailbox definition.

Note. The ability to create new transactions is unavailable if users don't have the permission to create that transaction.

The agent can search for and relate other emails to the current email, which changes the thread association. When the association occurs, only one outbound email can be selected at a time. If the outbound email has other threaded emails, the system updates their relationship with the current email as well.

See Also

Understanding Automated Mail Processing

Defining Mailboxes

Content Sources

The email workspace collects information from content sources to build an email response. There are implicit content sources that provide data to construct some portions of the response in a template format, such as the agent information for the closing part, the sender information for the greeting part, and the email information for the email history part. As for the content of the reply, it comes from these explicit content sources:

• Transactions that are enabled for ERMS.

  The concept of related transaction ensures that subinteractions are represented properly in the CRM system.

• Solutions.

  Solutions are thread-wide attributes, which means that when they are associated with the current email, they are actually linked to every email in the thread. So adding a solution to an email at any level associates this content with the entire thread.

When the agent works on the current email and selects solutions or related transactions on the email workspace, the system is essentially collecting content sources that can potentially be used in the email response. Collected items appear in the Template Search section of the Response page. Email workspace uses the selected content sources to refine the list of templates that are available in the Template drop-down list box for the agent to select. The selected items are also used as the content of the response to which one or multiple templates apply.

Similar to solutions, the agent can search for documents on the email workspace to be part of the email response. Documents are defined using the correspondence template package component, and the behavior of selecting a document is slightly different from selecting a solution. When the agent adds a document to the proposed list, the system automatically populates the document in the Template drop-down list box, which the agent can apply to the response if applicable.

Solution and Document Search

Solutions and documents are the two types of materials that an agent searches for to resolve email issues. They are kept in separate repositories, although the ways to search for them are similar. When an agent performs a Verity keyword search on solutions or documents, only one repository is searched at a time. The agent can set up email workspace preference to specify the default repository, default search mode (basic, advanced, or advanced with options) and additional search options (for example, word variation and number of search results to display) for document and solution search.

Note. The email workspace prevents solutions and documents that have already been attempted from being added to the content sources list again.

Solution Status Update

After the agent sends the email response that is associated with solutions, the agent can come back to the email and update the solution status based on customer's feedback. The system populates the Attempted Solutions grid of the More tab on the Email page with a list of selected solutions that were attached to the reply. If the customer contacts the agent later on about that email and confirms how effective those solutions were in resolving the issue, the agent can update the solution status accordingly.

See Also

Managing Inbound Email

Quick Action Buttons

The email workspace provides action buttons that enable agents to perform common email actions quickly. These buttons are context-specific; they appear in pages and sections where their operations are appropriate. These buttons represent generic email actions, such as reply, reply all, and forward, as well as other common actions that agents perform to resolve email issues. These common actions are subcategorized into these types:

• System-wide actions.

  Examples of system-wide actions are mark as spam and mark as duplicate. When the agent clicks any of these actions for an email, the email workspace updates the email's categorization information (spam or duplicate email), closes it, and removes its entry from the agent's worklist automatically.

• Transaction actions that are defined at the mailbox level.

  You can set up quick create action buttons for these types of CRM transactions to be created for emails if so configured: all types of cases, issues, orders and quotes, leads, opportunities, service orders, and service management objects. To minimize scrolling, PeopleSoft recommends that only one quick action button is specified for a mailbox. Scrolling is necessary if there is more than one transaction action button.

  Note. If the agent clicks an action button to create a transaction, the same operation takes place if the agent accesses the Recent Activities tab in the Assistance group box on the Email page and creates the same transaction.

Related Transactions

Certain types of emails can be handled through a direct response—much as you might respond directly to someone who calls you on the phone. Other types of emails can be handled more effectively through other CRM transactions, such as cases or leads that provide full-featured handling of customer support issues or product inquiries.

Related Transaction Types

You can associate emails with these types of CRM transactions:

• Cases.

  • Support cases.

    These include standard cases and cases that are specific to industry solutions.

  • Both PeopleSoft Enterprise Help Desk and Help Desk for Human Resources cases.

    If you use ERMS with either of these applications, pay attention when associating emails with cases. Associate email from external customers with support cases; associate email from internal employees with help desk cases.

• All types of captures in PeopleSoft Enterprise Order Capture.

  • Orders and quotes (both standard and specific to the insurance solution).

  • Service management, start service, stop service, and transfer service transactions.

  • Product application.

• Leads.

• Opportunities.

• Service orders.

You can relate an email to an existing transaction or create a new transaction. For example, if a customer sends an email with a support question, you can create a new case for that customer. If the customer later sends another email related to the question, you can relate the new email to the case that you already created. (If the new email is threaded with the original email, the system automatically carries over the case relationship to the new email.)

When you relate an email to an existing transaction, the system displays the appropriate search page for the transaction type that you select.

When you create a new transaction, the system saves the inbound email before transferring to the new transaction. You can create new transactions only if the email sender is fully identified; otherwise, the system gives an error and does not create the transaction. One way to verify this is by looking at the toolbar summary area. If the sender and the representing values appear as active links, that means the system has successfully identified the sender. If they are inactive, you must complete the identification manually before you can create transactions. For external mailboxes (in which case the email sender is a customer), the system gives an error and does not create transactions if the setID of the customer does not match the setID that is associated with the business unit of the mailbox.

When creating new leads, opportunities, and service orders, the system does not transfer data from the inbound email into the new transaction. Other types of transactions, however, include some default data that comes from the email (unless the default values are invalid for the user's default business unit). For example, the system populates the email sender information, subject, and body to new cases, and email sender to orders and quotes.

When possible, the system uses data from the email as the default data on the search page and in new transactions. In particular, the business object associated with the email is the default contact, whether you search for an existing transaction or create a new one.

Note. Access to secured cases in PeopleSoft Help Desk for Human Resources is available only to users who are members of the provider group to which the case is assigned. Users, who do not have this access, do not have secured cases available to them when they associate emails with cases. If a secured case is already associated with the email, users who do not have access to the case cannot see the case subject or access the case details.

Security for Related Transactions

The security profile of users controls their abilities to associate transactions with an email. For example, an agent who has security access to the support case component can also associate emails with support cases. In addition, the ability to relate or create transactions for an email comes from its mailbox. You specify at the mailbox level which CRM transactions agents can associate with and create for its emails in the Assistance group box on the Email page.

Because all types of captures use the same component, a user who has access to the component can create orders, quotes, and the various service-related transactions used in the industry solutions.

Email Replies

Agents reply to an inbound email through:

• The Response page of the email workspace.

  This page is used when the agent reviews an inbound email from the email workspace and wants to reply to it. The agent can respond to an email by accessing the Response page within the same component. Or, when the agent works on a transaction and wants to reply to an email that is associated with the transaction, the Response page for the selected email appears.

• The Outbound Notification component.

  This page is used when the agent works on a transaction and wants to create an email from that transaction (not responding to any email). If the Use Email Workspace while responding to an existing notification option is not selected at the system level, the Outbound Notification page is used for responding to existing email from a transaction as well.

  The Outbound Notification page is also used to view sent emails. Email approvers can access this page to approve emails from agents whose emails require approval before delivery.

These pages function in a similar fashion. They enable agents to:

• Compose a message using predefined correspondence templates or free-form text.

• Address the email and select the delivery channel (email or worklist) for each recipient.

  Normally, one sends the reply to the same address from which the inbound email was received, but if the agent copies other agents on the reply, the copies can be sent to those agents' worklists.

• Send the reply immediately or schedule it for future delivery.

  An agent who is associated with an approver (on the Agent Setup page) must, however, submit the reply for approval instead of sending it. The system sends the reply only after the approver approves it.

See Also

Approving Emails

Sending Manual Notifications

Replying to Inbound Email

Email Status Tracking

After an email arrives in a group worklist, its status is shown in the Status field. The agent assigned to the email can manually change its status on the email workspace. The system automatically updates an email's status when certain actions occur.

Note. The agent-facing email status is different from the process status that ERMS processes use.

See Email Process States and Incompletely Processed Email.

Email Statuses

There are three types of email status sets:

• Editable email status.

  This status set includes statuses that agents can update. This status set is available on the Email page under the Email Details section. Values are:

  • Open.

  • Closed - Response.

  • Closed - Canceled.

  • Closed - Duplicate.

  • Closed - Auto Response.

• System email status.

  This status set is maintained by the system and is not editable by agents. This status set is available on the toolbar summary area and the Message Detail page. The system email statuses are used in the interaction tree of 360-Degree View. This table lists the values:

  Status	Description
  New	The email process assigns this status after routing the email to a group worklist but before the email is assigned to an agent. It sets this status for the email automatically.
  Processing	This status is used to indicate that the system has not finished processing this email and cannot be accepted until the system has completed its work.
  Reassigned	The email is manually routed to a group worklist (either by requeuing or reassigning it), and it is not currently assigned to a specific user.
  Assigned	The email has been assigned to a specific user, but no reply has been sent. The system sets this status when the email is assigned to an individual, regardless of whether the user explicitly accepts the email or the assignment occurs by auto-acceptance.
  Completed	A user has handled the email and replied to it if necessary. The email workspace automatically closes the email after the user has submitted a reply on the Response page.
  Canceled	No action was required, and no reply was sent. Users can cancel email from the email workspace.

• Process state.

  Process states are statuses that the mail processor assigns to emails. The mail reader process refers to the process state of emails when resending them through the system. Process states are available on the Message Detail page. Values are:

  • Email Instance Created.

  • Queue for Routing.

    The email is processed by the mail reader process but is not yet processed by either the mail route process (based on type of email).

  • Auto Responded by System.

    The mail process responded to the email automatically.

  • Email Routed.

    The email is routed to a group worklist and is ready for to be processed by the agent.

  • Mailbox Forwarding.

    The mailbox reset functionality is performed.

The system enables you to close an email (as completed or canceled) whether or not any replies are sent. Normally, however, an email is closed after a reply is sent. If you suspect that additional correspondence is necessary to resolve an issue, you can use the email to create an appropriate related transaction, such as a case. The same set of values are used in interactions to represent email statuses.

See Reviewing Email Message Properties.

Email Status and Worklists

When viewing only ERMS worklist entries (and not ERMS alerts or all transactions), the worklist grid displays the email status; this makes it easy to see which emails are closed and to remove them all from the worklist at the same time. Sort the worklist grid by status to see which worklist entries can be marked complete.

The system prevents you from marking an ERMS worklist entry complete if the underlying email is not closed. This ensures that every email remains on a worklist until it is closed. (However, if you reopen an email after removing its worklist entry, the worklist entry is still marked complete. Do not rely on the worklist when working with reopened email.)

Reply Deadlines and Notifications

ERMS mailboxes and ERMS group worklists have a warning notification time period and a final notification time period. These are optional for group worklists but required for mailboxes. The ERMS alert processes trigger notifications based on these time periods. The system sends notifications if an email is still open at the notification deadline.

Note. Replying to an email does not prevent the system from sending the alert notifications. Although an email is automatically closed when its owner performs a response, the agent can reopen the email. Notifications occur if the editable email status on the Email page is open at the scheduled notification time.

The system sends notifications to the group worklist owner if the email is associated with a group worklist; otherwise, the notifications are sent to the mailbox owner. Email alerts are always sent to worklists, never to queues.

When filtering a worklist by transaction type, the email notifications appear under the ERMS Alert type (unlike email assignments, which belong to the ERMS type).

Warning notifications alert the recipient that the organization may miss a deadline, and final notifications alert the recipient that the deadline has arrived. Worklist notifications are calculated from the date and time that the worklist receives the email. If the email is reassigned to a different group worklist and then back to the original group worklist, the notifications are based on the most recent arrival time. Assignment of an email to an individual worklist does not affect the deadlines—nor does requeuing an assigned email back to its group worklist.

Worklist-level deadlines change as an email is reassigned to different groups. The deadlines represent the service organization's internal standards for timely replies.

Mailbox notifications are calculated from the time that the email enters the system. If the PeopleTools email table has a record of the time that the mail server received the email, that time is used. When the mail server data is unavailable (for example, POP3 mail servers do not provide this data), the system uses the time that the email was first saved in the PeopleSoft database. The delay between the time the mail server receives the email and the time that the email is saved in the PeopleSoft database depends on how often the mail reader process polls the mailbox.

Mailbox-level deadlines do not change as the email is reassigned to different groups. The deadlines represent the organization's external commitments for timely replies. The mailbox reset operation, however, can affect the mailbox-level deadlines. The new deadlines are computed based on the time that the email entered the system, not when the mailbox reset operation was performed.

The mailbox-level final notification time represents the final deadline for replying to the email. This deadline is the only one of the four notifications times that is visible on the toolbar; it is considered the email's due date.

All time periods are is calculated using a 24-hour clock, without regard to the organization's business hours. The warning dates and due dates (both internal and external) for these notification alerts are available on the Message Details page.

See Also

Worklists and Queues

The Email Alert Process

Setting Up and Using Worklists

System Information for Email Messages

Email workspace provides information that helps administrators to diagnose issues with emails from a system perspective. Similar to viewing the message source or message properties in other email systems, administrators can view email data that comes from CRM and PeopleTools in the Message Details page. System information includes the email status, state for the corresponding application engine process, email routing and assignment information, internal and external warning deadlines, message header details, and various parts that constitute the email.

See Also

Reviewing Email Message Properties

Accessing Inbound Email

This section discusses how to:

• Access inbound emails from the Multichannel Toolbar.

• Access inbound emails from My Worklist.

• Access inbound emails from the main navigation.

Note. You can also access an inbound email by using an interaction list (for example, from the 360-Degree View or in a transactional component's interaction history page) and on the Thread page of another email that belongs to the same thread.

See Also

Working with Interactions

Enterprise PeopleTools 8.50 PeopleBook: PeopleSoft MultiChannel Framework

Pages Used to Access Inbound Email

Accessing Inbound Emails from the Multichannel Toolbar

Access the Multichannel Toolbar.

Users must be configured as multichannel agents to access the multichannel toolbar. After an agent logs onto a multichannel queue from the toolbar, any incoming email task that is routed to this queue becomes available for acceptance. The system brings up the email workspace when the agent accepts the email, either manually or automatically.

Accessing Inbound Emails from My Worklist

Access the My Worklist page (My Worklist, Worklist).

Worklist entries are associated with a specific worklist. Inbound emails that you have accepted appear in your individual worklist. Emails that have not been accepted appear in group worklists. Notifications related to email deadlines appear in the individual worklist of the group worklist owner or, if the email was never assigned to a group worklist, in the individual worklist of the mailbox owner.

Worklist entries are also categorized by transaction type:

• Inbound email worklist entries are in type Email.

  These entries represent email assignments; they are created when an email is assigned to a worklist.

• Notifications related to deadlines are in type Email Alert.

See Also

Setting Up and Using Worklists

Accessing Inbound Emails from the Main Navigation

To access inbound emails from the main navigation, use the Search Inbound Emails (RB_EM_IB and RB_EM_IB_SRCH) components.

Access the Search Inbound Email page (Correspondence, Search Inbound Emails, Search Inbound Email).

You can control the behavior and appearance of this page using the CRM search configuration utility. The search criteria fields and search results fields are the same as the identically named fields in the email workspace. Click each page within the search results grid to view corresponding values of the emails that return.

Note that when emails appear in the Search Results section initially, they are displayed on the list by email ID in ascending order. If you click the Email ID column name to sort emails in the list by email ID, the system reorders emails (in ascending or descending order) by the first digit of the email ID.

See Also

Configuring Searches

Working with Inbound Email

This section provides an overview of the email workspace toolbar and discusses how to:

• Use the email workspace toolbar.

• Manage inbound email.

• Preview selected documents.

• Preview selected solutions.

• Find solutions and documents.

• Review email event history.

• Review email routing history.

• Review email audit history.

• Review email message properties.

• Review thread information.

• Reassign an email.

• Add email notes.

• Personalize email workspace.

• Submit email to another mailbox.

Understanding the Email Workspace Toolbar

Toolbars are configurable and customizable. In addition, you can give end-users the ability to personalize their toolbars.

See Configuring Toolbars.

PeopleSoft Enterprise CRM delivers these buttons for the email workspace:

The area beneath the toolbar button displays summary information about the email, which includes the email sender, email status, and the computed email due date. This date is based on the mailbox-level final notification time period.

If the final notification time period for the email's mailbox is two days, then the due date is two days after the email was received.

The customer value comes from PeopleSoft Enterprise Performance Measurement. This customer value appears if the sender is a consumer or the representing value is either a company or consumer.

See Delivered Common Toolbar Buttons.

See Understanding the Text Tray.

Common Element Used in This Section

See Also

Managing Inbound Email

Previewing Selected Documents

Previewing Selected Solutions

Finding Solutions and Documents

Pages Used to Work with Inbound Email

Managing Inbound Email

Access the Email page (Correspondence, Search Inbound Emails, Email).

Email Message

This group box displays basic information and the content of the inbound email. It appears on the Email page, the Response page, and the Search Solutions/Documents page to provide persistent email information wherever agents perform research.

Email Information - Main

This group box contains two tabs: Main and More.

The Main tab displays the email's status that agents work with. Agents can update these values manually.

The system provides action buttons to perform common email functions quickly. You can define these action buttons at the system or mailbox level.

See Defining Products, Defining Template Categories and Types, Defining Priorities and Moods.

Email Information - More

The More tab displays customer information. This tab also lists any CRM transaction that the email is associated with or any solution that the email has attempted to resolve its issue.

See Defining System Settings for Email Processing, Email Sender Identification, Quick Action Buttons.

Assistance

This group box provides recommended actions that the agent can choose to perform on the email and search capability on recent activities and transactions that relate to the email.

The Recommended Actions tab contains a list of recommended actions for the agent to perform. You can define a list of recommended actions based on category in the mailbox definition.

Recent Activities

This section contains a list of most recent activities that are associated with the sender of the email.

See Also

Assistance

Content Sources

Solution and Document Search

Previewing Selected Documents

Access the Document Viewer page (click a document link on the Email page, the Response page, or the Search Solutions/Documents page).

In addition to viewing the current document and navigate to other documents in the document list, you can also choose to add it to the proposed list, add it to the proposed list and reply the email with it.

See Common Element Used in This Section.

Previewing Selected Solutions

Access the Solution Viewer page (click a solution link on the Email page, the Response page, or the Search Solutions/Documents page).

See Common Element Used in This Section, Viewing External Content Solutions.

Finding Solutions and Documents

Access the Search Solutions/Documents page (Correspondence, Search Inbound Emails, Search Solutions/Documents).

Proposed Solutions/Documents

This group box contains the collection of solutions and documents that can be content sources for the email (for example, to perform template search) and can potentially resolve customer issues. You can select items in the list to send to customers. Selecting an item means that you are adding it to the list of content sources to be associated with the email and its possible response. When you perform search on solutions or documents on the Email page or the Search Solutions/Documents page and click the button to add selected items to the proposed list, the system populates those items here in the Proposed Solutions/Documents group box.

Search

This section allows you to perform keyword search against the selected repository (solutions or documents) using Verity.

See Common Element Used in This Section.

See Also

Solution and Document Search

Personalizing Email Workspace

Reviewing Email Event History

Access the History: Actions Taken page (Correspondence, Search Inbound Emails, History).

Actions Taken

This grid displays email history events that the system captures.

See Also

Understanding ERMS Setup

Reviewing Email Routing History

Access the History: Routing History page (click the Routing History link on the History page).

Worklist Scores

This grid displays the worklist routing score for the email. Based on the content analysis of the email that is performed by Verity, a routing score is computed for each worklist that is associated with the email's mailbox. The system then assigns the email to the worklist with the highest score. The email is assigned to the default worklist of the mailbox if no scoring information is available, for example, if none of the returned worklist scores meets the minimum threshold value that is set, or the mailbox is not associated with any worklists.

Routing History

This grid displays email routing events. The system creates a new row of data every time that the email is reassigned to a new group worklist or individual worklist.

See Also

Understanding Unstructured Email Routing

Reviewing Email Audit History

Access the History: Audit History page (click the Audit History link on the History page).

The Audit History grid displays record level and field level audit information, including the type of change performed (add, update, or delete), field values before and after the change, the user ID of the person who made the change, and the date and time of the change.

The PeopleSoft system is delivered with auditing features turned off. Turning on auditing can have a significant impact on application performance. Analyze your audit needs carefully to ensure that you turn on auditing only when there is a strong business reason to do so.

See Also

Setting Up Auditing for Cases and Inbound Email

Reviewing Email Message Properties

Access the Message Details page (Correspondence, Search Inbound Emails, Message Details).

Computed Message Body

This group box displays essentially the same email message that you see on most pages. The bigger display area enables for better readability.

System Disposition

This group box contains information about the email regarding status, routing, assignment, and response time deadlines that comes from the CRM system. It provides a visual indicator next to each response date and time that indicates if this email close to missing the deadline.

Message Header

This group box displays email data that comes from PeopleTools (with the exception of the Mailbox ID field). The values in the Date Sent and the Date Received fields are followed by a number, which is the respective time zone offset.

Customers can take advantage of the custom header information to drive additional business processes. PeopleSoft Multichannel Communications does not provide the infrastructure to facilitate customization projects of this kind.

See Enterprise PeopleTools 8.50 PeopleBook: PeopleSoft MultiChannel Framework

Multichannel Message Parts

This group box lists the message parts as stored by the PeopleTools Email Repository. A message part can be:

• The inline text, which can be a representation of the computed message body displayed on the left of the page.

• A sender specified attachment, which has a specific filename and content type.

• A PeopleTools generated attachment that is created when a system-size threshold is violated (meaning that the size of the text exceeds the threshold value) or the content type is not plain text. For example, if the mail client is configured to send both plain text and HTML email messages, two different parts appear in this section: a plain text part and an HTML part.

Reviewing Thread Information

Access the Thread page (Correspondence, Search Inbound Emails, Thread).

The construction of the thread tree on the left is based on the interaction thread information that is stored as part of a conversation. When you click an email link, the email content shows in the message area on the right. If you want to change the association of the current email (change email threading), perform the action on the Recent Activities tab on the Email page by relating the current email to another email as the new parent.

Reassigning an Email

Access the Select Worklist page (click the Reassign button on the toolbar).

Group Worklist Name	Select the group worklist where you want to reassign the email.
Individual (Optional)	Select the person in the selected group worklist to whom you want to reassign the email.
Reason	Select a routing reason. Use the following values for manual rerouting: Escalated, Misrouted, Overridden Reassigned, or Other. Other values that are used during automatic rerouting are also available. These values are Accepted, Bypassed, Encoding, Oversized, Requeued, and Routed.
Comment	Enter a comment that provides information about the reassignment. This is required if the routing reason is Other.
OK	Click to reassign the email to the selected worklist.

Note. Similar functionality is available from My Worklist.

Reassign Email Item to Selected Worklist

This section appears if Verity returns worklists in the Worklist Scores grid of the History: Routing History page. From the grid, select a group worklist and optionally select a member of the group. The last row of the grid is a free form field where you can enter any group worklist and optionally select an individual from that worklist.

See Also

Forwarding and Reassigning Worklist Entries

Adding Email Notes

Access the Note page (Correspondence, Search Inbound Emails, Note).

Here's some considerations for adding notes in the email workspace:

• You cannot email notes that you create for emails.

• Email notes don't use the visibility feature.

See Understanding Notes and Attachments.

Personalizing Email Workspace

Access the Email Workspace User Preferences page (click the User Preferences toolbar button on the email workspace).

Message Action

General Setting

Document/Solution Search

Default Settings

Basic Search Options

Advanced Search Options

Search Domains

Select the template package and solution specific fields as well as solution libraries that you want the system to use to search for documents and solutions.

See Also

Understanding PeopleSoft CRM Searching

Submitting Email to Another Mailbox

Access the Mailbox Reset page (click the Mailbox Reset toolbar button on the email workspace).

Replying to Inbound Email

This section discusses how to:

• Reply to inbound email from email workspace.

• Send emails from CRM transactions.

• Send emails from CRM transactions that are associated with emails.

• Review outbound email.

• Review outbound email thread information.

• Review outbound email notes.

You can reply to email either from the context of the email itself, or from the context of a transaction that is associated with the email. The methods are similar, except that when you reply from a transaction, you must explicitly indicate that you are replying to an email. In addition, you must identify the email to which you are replying.

Pages Used to Reply to Inbound Email

Replying to Inbound Email from Email Workspace

Access the Response page (Correspondence, Search Inbound Emails, Response).

Compose

If the system is unable to find any matching template for the email response when agents access the Response page, a warning message appears, and the Template Search section is expanded automatically. The agent can modify the classification criteria and refresh the template list.

You can set up the system to request notes from agents after they send email response or submit them for approval. If agents are email owners, sending responses automatically updates the email status to closed - response, removes the email item from the owner's individual worklist, and deletes the email task from the Multichannel Toolbar if the email was opened from it. In this case, the message about adding a note, if enabled, appears after these tasks are completed.

Sending Emails from CRM Transactions

If you click the Notification button on the toolbar from a transaction to send an email, the system either transfers you directly to the Outbound Notification page to start a new email thread, or displays a page where you can select to start a new thread or reply to an existing email of the transaction.

If you select to reply to an existing email, the Response page of the email workspace appears.

If you select to start a new thread, the Outbound Notification page appears where you compose the new message. If the Use Email Workspace while responding to an existing notification option is selected, the Response page is used instead.

Note. The Thread page is not available when you create an outbound email; you will see the information when you review the outbound email by navigating under Correspondence, Outbound Emails, Outbound Email.

See Also

Sending Manual Notifications From CRM Transactions

Sending Emails from CRM Transactions That Are Associated with Emails

Access the Email Reply or Start New Thread page (click the Notification button from the toolbar of a transaction (for example, case), which you navigated to from another email).

Email Operation

When you click the Notification button on the toolbar of a transaction, you see this page if you previously navigated to the transaction from an email or if the transaction is associated with other emails. This page is available only if PeopleSoft Multichannel Communications is licensed.

Note. This page does not appear if the transaction is not associated with any inbound emails. Agents are transferred directly to the Outbound Notification page to start new email thread.

Reviewing Outbound Email

To search for and review outbound email, use the Search Outbound Emails (RB_EM_OB and RB_EM_OB_SRCH) components.

Access the Outbound Email page (Correspondence, Search Outbound Emails, Outbound Email).

The Outbound Email component is in read-only mode when you access it from the menu navigation. The interface is similar to the Response page of the email workspace. You can review the content of the outbound email and the corresponding inbound email. The interface also lists any related transactions and solutions for the email, and as well as the template used to format the final email body.

Email approvers use the Outbound Email component to approve or disapprove emails. If you associate an agent with an approver in the system, the system sends an action request worklist entry to notify the approver whenever the agent sends an email. The approver must approve the email before it is delivered. When the approver clicks the approval request link from the worklist, the system opens the email in the Outbound Email page. The approver can edit the subject and message before clicking the Approval button on the toolbar, or disapprove it. The email is sent when it's approved; if it's not approved, the system sends a notification to the agent indicating that the email has been disapproved.

For agents whose emails require approval before delivery, the Submit for Approval button appears on the Response page instead of the Send button.

Reviewing Outbound Email Thread Information

Access the Thread page (Correspondence, Search Outbound Emails, Thread).

The system uses the same Thread page for inbound and outbound emails.

See Reviewing Thread Information.

Reviewing Outbound Email Notes

Access the Note page (Correspondence, Search Outbound Emails, Note).

The system uses the same Note page for inbound and outbound emails.

See Entering and Viewing Notes.