Understanding Email Management

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 Email Workspace User Preferences Page.

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 these topics. This table summarizes the actions that are available to different users depending on whether the email is currently assigned:

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.

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 Email Page.

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.

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.

See Understanding BO Search and Quick Create Setup.

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 Group Worklist Page, 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.

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.

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 Worklist Routing Efficiency Page.

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.

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.

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.

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.

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.

Related Transaction Types

You can associate emails with these types of CRM transactions:

• Cases.

  • Support cases.

  • Both PeopleSoft 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.

• Orders and quotes in PeopleSoft Order Capture.

• 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.

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 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.

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

See Message Details Page.

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.)