Defining Unstructured Email Routing Rules

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

• Define customer-based routing rules.

• Define context-based routing rules.

• Define content-based routing rules.

• Apply content-based routing rules to a mailbox.

• Set up Automated Mail Processing.

Note. Throughout this chapter, the term worklist refers to both ordinary group worklists and to PeopleSoft MultiChannel Framework queues. The term customer refers to external customers and, if you use the email response management system (ERMS) with help desk applications, to the employees that the help desk serves.

See Also

Defining Worklists

Understanding Multichannel Applications and Universal Queuing

ERMS Processes

Understanding Unstructured Email Routing

The system's ability to analyze an unstructured email and perform a predefined action based on the analysis or route it to an appropriate worklist, is crucial to an efficient email response process.

This section discusses:

• Routing methods.

• Content-based routing using natural language processing (NLP).

• Content-based routing using Verity.

Note. This chapter applies only to mailboxes for which you have enabled routing based on email analysis or automated mail processor (AMP) actions; the chapter does not apply to mailboxes that route all emails to a default worklist.

Routing Methods

The Unstructured Email process analyzes emails to determine the worklist whose members are most qualified to reply. The process that determines the appropriate worklist has several routing methods, as shown in the following diagram:

Note. In this diagram, the content-based routing is performed by Verity. If the natural language processing (NLP) system is installed, AMP replaces Verity to be responsible for content-based routing. Refer to the Content-Based Routing Using NLP section for more information and an illustration of AMP.

Routing process for unstructured email

When the routing process starts, it loops through each email, attempting to route each one in turn.

Thread-Based Routing

Outbound emails sent through the PeopleSoft Customer Relationship Management (CRM) correspondence management system (ad hoc emails and email replies) include an identifier known as a context tag. If the recipient replies to the email and includes the context tag in the reply, the routing process uses the tag to identify the parent email (the email to which the sender replied).

If the parent email was sent through the ERMS (that is, the parent was a reply to another inbound email), the system sends the new email to the last group worklist associated with the previous inbound email.

For example, suppose that a customer sends an email (email A) to report a printer problem. This email is routed to the Laser Printers group worklist, and then it is rerouted to the Color Ink Jet Printers group worklist. An ERMS user replies (email B) asking for more information. This reply contains a context tag. The customer then replies (email C) with the requested information. Email C contains the context tag that originated in email B. When the system processes email C, it recognizes the context tag, traverses the thread to determine that email A is the previous inbound email, and routes email C to the Color Ink Jet Printers group worklist. If the ERMS user sends another email back to the customer (email D), the email message will have the same context tag as the previous emails in the thread.

If the parent email was an ad hoc email, there is no worklist already associated with the thread. In this case, the system establishes the sender of the original ad hoc email and routes the email to that user's default group worklist as established on the Agent Setup page. If the user does not have a default group worklist, the system routes the email to the mailbox's default worklist.

Note. Thread-based routing works only when the context tag is present. To increase the probability that customers will include the context tag when they reply to an email, the outbound email should instruct customers to include the context tag in reply messages.

Customer-Based Routing

Customer-based routing enables you to route emails based on factors such as customer value.

If an email is not routed by the thread-based routing process, the system next checks the email's business object ID (as determined by the Mail Reader process). If the business object ID is the one that you use for unknown senders, the customer-based routing option is not available. However, if the business object ID represents an actual customer, the system performs any customer-based processing that you include in the routing process. PeopleSoft CRM does not come with any customer-based routing rules, only an infrastructure that you can use to plug in your own rules.

The customer-based routing method is available only with emails for which the sender is a known customer. However, because your organization is responsible for designing and implementing this type of routing, you can route the email based on any criteria you like, not just the identity of the sender.

Note. Remember that the word customer can refer to employees as well as to external customers.

Context-Based Routing

Context-based routing enables you to route an email based on the sender's email address. You can set up routing based on both fully qualified email addresses and on email domains (the portion of the email address that follows the @ symbol).

For example, to route all email from company XYZ to the preferred customer worklist, set up domain-based routing rules so that all email from the domain xyz.com is routed there.

If an email meets criteria for both address-based and domain-based routing, the address-based routing takes precedence.

Content-Based Routing

Content-based routing involves analysis of the content of an email message to route the email to a group worklist whose members have certain skills.

There are two types of content-based routing in ERMS: one with NLP and the other one with Verity.

Content-based routing uses NLP, a third-party categorization application, to perform content analysis on unthreaded email and return suggested categories and threshold scores. By matching the email categories and scores with predefined rules associate categories with actions, the system can invoke proper actions to handle preliminary and common email processing (for example, respond to transaction status inquiry) in an automated fashion, reducing workload for agents. The routing process includes a rules engine, which is a batch process that runs periodically behind the scenes to process email from different mailboxes in a sequential manner. It matches email categories and threshold scores with active category rules that are associated with the mailbox. If the rules engine finds a rule that applies to the email, it triggers the specified action(s) automatically.

If NLP is unavailable, content-based routing uses Verity, a third-party searching application, to search each email for keywords that you establish. You associate different worklists with different groups of keywords. By comparing the scores for each group of keywords, the system determines the worklist to which it routes the email.

The routing process runs as part of a job that also includes a process to build the Verity collection that the system uses for content analysis. The collection includes all emails in the unstructured email queue.

Each instance of the Build Collection process (RB_SRCH_BLD) overwrites the collection files that the previous instance of the process created. Because the system does not remove email from the unstructured email queue until it has been successfully routed, an email that is not routed because of a failure in the routing process remains in the queue and is included in the next iteration of the Verity collection.

The content-based routing process is described in more detail in the following sections.

Default Routing

If none of the previous routing methods identifies an appropriate worklist, the system routes the email to the default worklist for the mailbox. Every mailbox must have a default worklist.

See Also

Defining System Settings for Email Processing

Understanding PeopleSoft CRM Searching

Content-Based Routing Using NLP

This section describes the content-based routing process using NLP and elements that the system uses in this process. This diagram illustrates the AMP process flow that is enabled through NLP:

Automated mail processing

Categories

The AMP framework triggers actions to process email based on matching the category and threshold of an email to a list of rules that you define in the system. You specify categories into which email can be classified in the NLP framework. When an email is sent to NLP, NLP analyzes its content and suggests one or more categories and corresponding threshold score for the mail (for example, this email belongs to the problem category with a relevance score of 80). The system uses this information to find a matching rule and invokes the action associated with that rule.

PeopleSoft CRM delivers categories that can be used for AMP. They are specified under a category set called AMP Categories, including Problem, Inquiry, Spam, Complaint, and Unsubscribe. To add custom categories to the AMP category set, create them under Set Up CRM, Common Definitions, Correspondence, Categories & Types. Subsequently, add them to the AMP Categories category set under Set Up CRM, Common Definitions, Knowledge Base, Category Set.

Actions

The idea behind the automated mail processing is that the system can take actions immediately on the kinds of email that are relatively common and straightforward in terms of their purposes, such as making a complaint, filing a product problem, or requesting status information. It reduces agents' workload and helps them focus on resolving more complicated issues that are routed to them. You define email-specific actions that AMP can trigger using the action framework of AAF. The framework provides a flexible environment which allows you to implement custom actions by referencing your application class method in the runtime section of the action type definition. Specify an application class method in the design time section of the action type definition if you need to gather more details about the action from customers. The system triggers the design time code of an action when customers specify the action in a rule definition. Clicking the Configure link on the Define Automated Mail Processor Rule page allows customers to enter additional configuration details about that action for a particular rule.

System-delivered actions include Auto response, Auto acknowledge, Auto route, Auto suggest, Create case, Spam and Unsubscribe.

Rules, Rules Engine and Mailbox Relationships

You associate a category with actions in a rule, which is evaluated by the rules engine to determine which action to trigger for each email it processes. In a rule definition, you specify the minimum confidence (threshold) score that an email of the same category has to meet for this rule to be applicable to it. You can specify one or more actions in a rule to invoke and prioritize them. When the rules engine gets the suggested category and threshold score for an email from NLP, it gets the rule that is associated to that email category from the mailbox definition. It tries to take the action of the highest priority, one level at a time. If it cannot take the action for some reason (for example, the returned threshold score of the email is lower than the one specified at the action level), it moves to the next priority to see if it can trigger any action. If the rules engine cannot find any rule, or there is no action that can be triggered from the applicable rule due to low threshold score, the email is then routed to the default group worklist specified in the mailbox definition.

Note. If any action that AMP invokes for the email doesn't involve routing, the system sends it to the default group worklist automatically.

PeopleSoft CRM delivers AMP rules for categories created in the system:

In addition, associate category rules with mailboxes. The rules engine references this information when it looks up possible rules that can apply to a categorized email that belongs to a particular mailbox.

Analysis Steps

Here is a summary of the automated mail processing:

• The mail reader process calls the rules engine to handle the email after verifying that NLP is installed in the system. The email is not threaded, and neither customer-based nor context-based routing rules apply. The email is sent to NLP for content analysis.

• NLP returns a category and threshold score for the email. The rules engine gets a list of rules for that suggested category from the mailbox definition that the email belongs to.

• For each rule that applies, the rules engine goes through the rule's actions to find the one with highest priority that it can trigger for the email.

• If the rules engine can find a matching action, it executes the action accordingly. If not, it routes the email to the default group worklist specified in the mailbox definition.

• Removes the email from the unstructured email queue.

See Also

Understanding Natural Language Processing

Content-Based Routing Using Verity

This section describes the content-based routing process using Verity and the elements (queries, query groups, and worklists) that the system uses during content-based routing.

Queries and Query Groups

Content-based routing of this kind is based on matching the text in an email to a list of keywords that you define, when NLP is not available. You define the keyword lists at two levels. Queries are lists of weighted keywords. You assemble the queries into query groups.

For each query group, the system builds a Verity Query Language (VQL) statement based on the keywords in all the associated queries. Executing the VQL statement yields a score that indicates how well the email matches the keywords in that query group.

Defining VQL at the query group level and keywords at the query level can significantly reduce your keyword data entry and maintenance. For example, if you use 10 worklists for handling printer-related issues, you can define one query with keywords that are common to all printers and additional queries with keywords for certain types of printer issues. You can then set up query groups for each type of issue, and each query group's VQL references the common keywords in addition to the more specific ones. You do not need to enter or maintain the set of common keywords in 10 different locations. The reusability of queries and query groups makes the configuration of content-based routing rules more efficient.

You can also create your own VQL statement (either from scratch or by modifying the system-generated VQL). Once you set the query group definition to use user-created VQL, any queries associated with the query group are no longer relevant. Changes to the query or the query group do not update your custom VQL unless you copy the updated system-generated VQL again.

Typically, you create queries and have the system create the VQL for you. If, however, you prefer to write your own VQL, you do not need to create queries. If you create queries and write your own VQL, remember that the system does not use the queries when the user-defined VQL is in use. Also, remember to validate your VQL; the routing process does not use custom VQL that has not been validated.

ERMS Worklists

Each mailbox definition includes a list of worklists that are possible targets for content-based routing. Not only does this list help to focus the routing process, it also improves performance. The system obtains scores for relevant query groups only, and you can easily limit the number of queries executed for each email.

Worklists are associated with one or more query groups so that the query group scores can be used to calculate worklist scores. Two methods exist for calculating worklist scores: average query group score and highest query group score. You set this option for each mailbox that you define. Once the routing process calculates the scores for all potential worklists associated with a mailbox, it routes the email to the worklist with the highest score.

During the content analysis, the system records worklist scores so that you can view them later in the email routing history in the Inbound Email component. When rerouting an email, you can refer to this scoring history to evaluate other potential worklists.

If the score is based on the highest query group score, the system also records (but does not display) the query group that achieved the score. If a worklist has more than one query group with the highest score, the priority that's set in the query group and worklist association determines which query group is considered the one that achieved the highest score.

Query, Query Group, Worklist, and Mailbox Relationships

Content-based routing is based on the following object associations:

• Queries to query groups.

• Query groups to worklists.

• Worklists to mailboxes.

The system routes an email to one of the mailbox's worklists—the one with the highest score. The system calculates the worklist's score based on the scores for the associated query groups. The system determines the query group score based on a VQL statement that includes keywords from the queries that are associated with the query group.

The following diagram illustrates these relationships:

Relationships of content analysis objects

In this diagram, an organization is using separate mailboxes for its North American and European support operations. In North America, the organization has separate group worklists to support laser printers and inkjet printers; in Europe, there is one group worklist for all printer types.

Because the North American support operation needs to separate laser printer issues from inkjet printer issues, there are separate query groups for each printer type. The European worklist is associated with both query groups, each North American worklist is associated with one.

Both of the query groups reference a shared query with general printer keywords. Two other queries provide lists of laser printer keywords and inkjet printer keywords to the appropriate query group.

Note. Queries use the PeopleSoft related language architecture, so if a query definition contain keywords in several language, the associated query group definition contains VQL for each language. During content analysis, the system applies the VQL that corresponds to the language code from the mailbox-specific run control for the Build Collection process.

Analysis Steps

Here is a summary of the process for content-based routing:

1. The system identifies the mailbox to which the email was sent.

2. Based on the mailbox definition, the system determines which worklists are valid targets.

3. The system determines which query groups are associated with those worklists.

4. The system executes the VQL for each query group and records each email's score for each query group.

5. The system determines the score for each worklist, using either the highest query group score or the average query group score.

6. If no worklist achieves the minimum threshold that you set, the email is routed to the mailbox's default worklist.

7. If at least one worklist achieves the minimum threshold, the system routes the email to the worklist with the highest score.

   To break a tie, the system uses the worklist priorities that you set within the mailbox definition.

8. The system performs the following post-routing processing:

   1. Sends an auto-acknowledgement email to the sender, if the mailbox is configured for acknowledgements.

      The system skips this step if the email has a context tag. Consequently, customers do not receive acknowledgements for every email in an ongoing conversation; they receive an acknowledgment for the initial email only.

   2. Sets the email's processing status to Routed.

      The processing status is different from the email status that agents see on the Inbound Email page.

      See Understanding ERMS Processes.

   3. Removes the email from the unstructured email queue.

Note. Content analysis analyzes email body text that is stored in the PeopleSoft CRM tables. It does not analyze content that is stored as an attachment. When the size of an email causes the system to store its entire content as an attachment, content analysis is not possible and the Unstructured Email process routes the email to the mailbox's default worklist.

Defining Customer-Based Routing Rules

This section discusses how to:

• Define an application class with customer-based routing rules.

• Apply customer-based routing rules to a mailbox.

Page Used to Define Customer-Based Routing Rules

Defining an Application Class with Customer-Based Routing Rules

To implement customer-based routing rules, create an application class that performs the necessary analysis and identifies the target worklist.

PeopleSoft CRM provides a base class called CustomRouting that you extend when creating your own routing processing. The delivered base class is located in the RB_ERMS package.

Sample Code

The following sample code returns a worklist called SpecialVIPService. The worklist name is passed to the Unstructured Email process, which routes the email to that worklist.

class CustomRouting
   method TargetWL() Returns string
end-class;

method TargetWL
   /+ Returns String +/
   Local string &Target_Worklist;
   
   /* Custom-based routing here and determine the target worklist to route the email to. In this example, the emails will
be routed to the group worklist, 'SpecialVIPService'
   
   &Target_Worklist = "SpecialVIPService";

   */
   Return &Target_Worklist;
end-method;

Applying Customer-Based Routing Rules to a Mailbox

Access the Mailbox Definition page.

In the Unstructured Email Processing group box, enter the ID and path for the application class to be used.

See Defining Mailbox Settings.

Defining Context-Based Routing Rules

This section discusses how to define context-based routing rules.

Page Used to Define Context-Based Routing Rules

Defining Context-Based Routing Rules

Access the Exception Routing page.

Reply To	Enter a fully qualified email address. Email received from this address is routed as specified on this page and does not go through content-based routing.
Domain	Enter an email address domain (the part of an email address that follows the @ symbol). Email received from any address in this domain is routed as specified on this page and does not go through content-based routing.
Worklist Name	Select the group worklist to which the system routes email from the specified address or domain. Click the Email Group Worklist button to access the corresponding group worklist definition.
Comment	Enter an optional comment that explains why email from the address or domain is routed to the specified worklist.

Defining Content-Based Routing Rules

This section discusses how to:

• Define queries.

• Define query groups.

• Associate query groups with worklists.

Note. This section only applies to content-based routing using Verity.

Prerequisites

Before you set up content-based routing rules, you must:

• Define the group worklists to which the content-based routing process routes email.

• Define the mailboxes that use the content-based routing rules.

See Also

Setting Up and Using Worklists

Defining Mailboxes

Pages Used to Define Content-Based Routing Rules

Defining Queries

To define queries, use the Query/Keyword Details (RB_QUERY) component.

Access the Query/Keyword Details page.

Active Flag	Select Active (the default) or Inactive. When the system creates the VQL for a query group, any inactive queries are ignored.
Exact Match	Select to search for an exact, case-sensitive, match. If you leave this check box clear, the system-generated VQL statement not only performs case-insensitive searches, it also searches for words based on the same stem. For example, if this check box is cleared and the query includes the word process, the system accepts the words processes and processing as matches.
Keyword or Phrase	List the words and phrases to include in the query. Entries that include more than one word are treated as phrases; the email matches the search criteria only if the entire phrase is present. Any punctuation that you include in the phrase is part of the phrase.
Weight	Assign a weight from 1 to 100 that corresponds to the relative importance of the word. When the system creates the VQL for a query group, this weight is applied to the keyword and is factored into the final query group score.

Note. Any change to a query's keywords, phrases, or weights automatically updates the system-generated VQL statements in all query groups that reference the modified query.

Defining Query Groups

To define query groups, use the Query Grp/System Associations (RB_QUERY_GROUP) component.

Access the Query Groups page.

Main Query Group Setup

Verity Query Language String

Queries

Associating Query Groups with a Worklist

To associate query groups with a worklist, use the Query Grp/Wrklist Associations (RB_WL_ROUTING) component.

Access the Query Group/Worklist Associations page.

Worklist Name and Queue	Displays the worklist whose query group associations you are defining. The read-only Queue check box is selected if the worklist that you are configuring is defined as a queue on the Group Worklist page.
Query Group ID	Select the query groups to associate with this worklist. Only active query groups are available for selection. If you inactivate a query group after associating it with a worklist, the query group is not used to determine the worklist's score. Query groups can be associated with multiple worklists.
Query Group Name	Displays the name of the query group as defined on the Query Groups page. Click the query group name to access the Query Groups page, where you can review the query definition.
Priority	When worklist scores are based on the highest query group score, the system records (but does not display) the query group that achieved the score. If a worklist has more than one query group with the highest score, the priority that you set here determines which query group is considered the one that achieved the highest score. Enter a priority from 1 to 999. Highest priority is given to the query group with the lowest value: priority 1 is higher priority than priority 2. This priority does not affect the routing, only the statistics that the system keeps. When worklist scores are based on average query group scores, this field is not used.

Applying Content-Based Routing Rules to a Mailbox

This section discusses how to:

• Associate AMP rules and worklists with a mailbox.

• Review worklist statistics for a mailbox.

• Review the content-based routing rules for a mailbox.

Pages Used to Apply Content-Based Routing Rules to a Mailbox

Associating AMP Rules and Worklists with a Mailbox

Access the Associate Rules and Worklist page.

Behavior Summary

Use this group box to associate categories and category rules with the mailbox. The rules engine triggers actions to process incoming email automatically based on the email category that returns from NLP and the predefined rule that is set up for that category. This group box does not appear if NLP is not installed.

See Setting Up Automated Mail Processing.

Associated Worklists

Reviewing Worklist Statistics for a Mailbox

Access the Worklist Routing Efficiency page.

Email Routing Statistics

Emails Reassigned and Completed in Other Worklists (Top 3)

As elsewhere on this page, the statistics in this group box relate only to email sent to the current mailbox and originally routed to the worklist whose efficiency information you're viewing.

Reviewing the Content-Based Routing Rules for a Mailbox

Access the Content Routing page.

Reload Tree

Click to update the information in the analysis hierarchy tree based on the most current content-based routing definitions.

Analysis Hierarchy

The tree in this group box provides an overview of the content-based routing rules associated with the current mailbox. Each node on the tree is a link that you can click to view the definition of the underlying object.

The tree includes the following elements:

• The root node of the tree represents the current mailbox.

  Click the link to displays the Mailbox Definition page.

• Second-level nodes represent the worklists that have been associated with the mailbox on the Associate Rules and Worklist page.

  Click the link to display the Query Group/Worklist Associations page.

• Third-level nodes represent the query groups that have been associated with the worklists on the Query Group/Worklist page.

  Click the link to display the Query Groups page.

• Fourth-level nodes represent the queries (keyword lists) that have been associated with the query group on the Query Groups page.

  Click the link to display the Query/Keyword Details page.

  Note. If the query group uses custom VQL, the associated queries are not a reliable indicator of the query group content.

Key to Icons

Except for the root node, representing the mailbox, every node in the analysis hierarchy tree includes an icon that visually indicates the type of object represented.

Setting Up Automated Mail Processing

This section discusses how to:

• Define categories.

• Define actions.

• Define rules.

• Configure auto response actions.

• Configure auto acknowledge actions.

• Configure case creation actions.

• Configure auto suggest actions.

• Configure spam actions.

• Specify auto acknowledgement options in mailboxes.

• Associate mailboxes with categories and rules.

Pages Used to Set Up Automated Mail Processing

Setting Up AMP Categories

Access the Category Set page.

PeopleSoft CRM delivers a set of categories that can be used by NLP to classify email after analyzing its content. To add custom categories to be used for AMP, define them first in the Categories & Types page.

See Understanding Natural Language Processing, Defining Template Categories and Types.

Defining Actions

Access the Register Action Type page.

AMP leverages the action framework of AAF to define actions. Use these fields on the page to define actions that are triggered by the rule engine.

The system delivers actions that can be used by the rule engine to handle some of the common email scenarios. Customers can add custom actions by writing their own application class methods and reference it here.

Defining Rules

Access the Define Automated Mail Processor Rule page.

Behavior Name and Description	Enter the name that uniquely identifies the rule, and enter descriptive text to explain the sequence of actions for this rule. The system uses the text in the Description field to display rules (for each category) in the mailbox definition.
Category	Select a category from the drop-down list box to associate with this rule. It lists all the categories that are available in the system-delivered category set called AMP Categories.
Confidence Must Exceed	Enter the minimum threshold value that an email needs to obtain for the specified category before this rule can apply. NLP processes email and returns one or more categories and their threshold values. The system uses the threshold value to determine which rule to apply to the email if NLP returns multiple categories (the highest wins). If more than one threshold value exceeds the confidence value specified in this field, the rules engine doesn't apply any rule to the email; instead, the email is routed to the default group worklist of the mailbox.
Priority	Enter the number to prioritize actions. The small the number, the higher the priority. The rules engine triggers actions with the highest priority. If no actions from the first priority can be invoked, it attempts the actions with the next highest priority. For example, the AMP rule is associated with three actions, auto response (in priority 1), create case and auto route (both in priority 2). If an email matching this rule's category exceeds this rule's confidence level, the auto response action is invoked. If this action cannot complete, the create case and auto route actions are triggered. If none of them can succeed, the system sends the email to the default group worklist of the associated mailbox. You can assign the same priority to multiple actions.
Action Type Name	Select the type of actions that the rules engine invokes.
Configure	Click to access the page to enter configuration details for the specified action type. A message appears if you click the link to configure an action type but it doesn't require any configuration. Each delivered action type has its individual configuration page where you specify action-specific configuration information.

Configuring Auto Response Actions

Access the Configure Auto-Response Action page.

Configuring Auto Acknowledgement Actions

Access the Configure Auto-Acknowledge page.

Select a correspondence template package used to format the acknowledgement email.

Configuring Case Creation Actions

Access the Configure Create Case page.

Select the display template used to create the case.

Configuring Auto Suggest Actions

Access the Configure Auto-Suggest page.

Auto-Suggest

Maximum Number of Documents

Configuring Spam Actions

Access the Configure SPAM page.

Delete SPAM from System	Select to remove spam email from the system.
Mark as Spam and Route to WL (mark as spam and route to worklist)	Select to mark email as spam and route it to the worklist specified in the Group Worklist Name field.
Route email to a Spam Mailbox	Select to route spam email to the mailbox specified in the Spam Mail Box ID field.

Specifying Auto Acknowledgement Options in Mailboxes

Access the Mailbox Definition page.

Select how you want to handle auto acknowledgement in the Auto Acknowledgement group box.

See Defining Mailboxes.

Associating Mailboxes With Categories and Rules

Access the Associate Rules and Worklist page.

Behavior Summary

This group box does not appear if NLP is not installed.

Associated Worklists

Use this group box to associate worklists with a mailbox and prioritize worklists for that mailbox.

See Associating AMP Rules and Worklists with a Mailbox.

Specifying Rules for Categories

Access the Select Rule page.

Select one rule for each active category that is associated with a mailbox. Click the rule link to access the Define Automated Mail Processor Rule page to view the rule definition and modify it as needed. After selecting a rule, the Configure link becomes active. and return to the Associate Rules and Worklist page, the rule link appears. Click it to access the Define Automated Mail Processor Rule page.

When you select a rule, its Configure link becomes active. Click this link to access the Configure Actions on Mailbox page (RB_MB_CFG_ACTIONS) and configure the actions available in the rule.

Configuring Rule Actions for Mailboxes

Access the Configure Actions on Mailbox page.

This page contains the configuration parameters required for all the actions associated to the selected rule. If there are actions of the rule that do not require further configuration, they are not shown here. The fields for each type of actions are identical to those that appear on each individual action configuration page that are discussed in this chapter.