Understanding Structured Email

Structured email is generated from a web page where customers enter and submit information. The web page takes the information that customers enter, applies XML markup, inserts a webform ID, and sends the XML as an email to a mailbox that the PeopleSoft CRM email response management system monitors. When the mail reader process (RB_MAIL_READ) analyzes the email, the presence of an XML header causes the system to classify it as structured email and be processed by the mail route process accordingly.

The email is displayed in plain text on email workspace for agents to review or process further. On the email body, each piece of data has a corresponding text label that is defined in the webform definition for better readability.

If the email process cannot identify the webform ID, it routes the email to the admin group worklist for the mailbox.

The web page where customers submit email exists outside the PeopleSoft system. To ensure proper handling of structured email, the email generated by the external webform must include a WEBFORM_TEMPL_ID tag with a webform ID that you set up within the PeopleSoft system. You define the ID on the Define Webform Templates page, where you also select the application message that represents the webform structure. The page has a preview option so that you can see the expected format of all emails that are generated from this webform. Validate the actual email that the external web page generates against the expected format that appears in the preview.

Because the webform where the structured email originates is external to the PeopleSoft system, its design is completely up to you. For example, you could use a webform exclusively for inquiries about the status of a service order, or you could use the same webform for several types of inquiries. Regardless of how you design the webform, it is your responsibility to ensure that the email it generates always contains a unique webform ID and a structure that matches the structure of the webform template within the PeopleSoft system.

Webform templates specify the XML format that is used to generate structured emails after customers enter information on corresponding webforms. A webform template consists of the following elements:

• Inbound service operation.

  The message sets the expected format of the XML in the email body. Fields that you include in the message definition must appear in the XML, and the names of the XML tags must match the field name or its alias (if you defined an alias).

• Application service input type.

  This element tells the mail reader process how to pass the email body to the application class method (used in actions). If the input type is XMLDOC or Rowset, the system converts the email body text to the specified format. If the input type is Custom, the application class must perform any necessary conversion.

  The easiest input format to work with is normally a rowset; the message definition determines the rowset structure.

• Default category.

  The rules engine uses this category to locate the appropriate rule and action for the email if the associated webform is set to always use the default category as the email category. The default category is also used if the engine cannot identify an email category with a threshold value that exceeds the category's confidence level.

• Mapping between webform fields and email workspace fields.

  The rules engine uses this mapping to populate webform data to corresponding fields in the email workspace in a readable manner (in plain text without XML tags).

<?xml version="1.0"?> 
<Message> 
<MsgData> 
<Transaction> 
<RO_HEADER class="R"> 
<CAPTURE_ID></CAPTURE_ID> 
<BILL_RECIPIENT_FLG></BILL_RECIPIENT_FLG> 
<BULK_ORDER_FLAG></BULK_ORDER_FLAG> 
<PROD_TERM_CODE></PROD_TERM_CODE> 
<DUE_DATE></DUE_DATE> 
<RESELL_FLAG></RESELL_FLAG> 
<RO_BILL_TO_TYPE></RO_BILL_TO_TYPE> 
<SCHEDULE></SCHEDULE> 
<SUBMIT_DTTM></SUBMIT_DTTM> 
<UID20F_PARTNER></UID20F_PARTNER> 
<UID20F_PARTNERC></UID20F_PARTNERC> 
<FIN_ACCOUNT_ID></FIN_ACCOUNT_ID> 
<RO_MULTILINE></RO_MULTILINE> 
</RO_HEADER> 
<RB_WEBFORM_SBR class="R"> 
<WEBFORM_TEMPL_ID></WEBFORM_TEMPL_ID> 
<FROM_ADDRESS></FROM_ADDRESS> 
</RB_WEBFORM_SBR> 
</Transaction> 
</MsgData> 
</Message> 

Structured email processing follows this sequence:

1. A customer submits data using a webform.

2. The webform creates an XML-formatted email message containing transaction information, a webform ID, and the customer's email address.

3. The email arrives in an mailbox that is monitored by your ERMS system, and the presence of the XML header causes the mail reader process to classify it as a structured email.

4. The mail route process converts the email from XML to plain text using the webform and email workspace field mapping that is set up as part of the webform template definition.

5. The mail route process identifies the default category from the webform definition that is associated with the email, and checks if the option to always use the default category is selected in the webform definition.

   If yes, the system uses the default category as the email category, looks up any AMP rules that are associated with it, and performs rule actions on the email. If the default category is not associated with any rules, the system routes the email to the mailbox's default group worklist.

   If no, the AMP rules engine uses PeopleSoft Search to identify either the most appropriate group worklist to route the email (if automatic routing is enabled), or the category of the email (if automatic routing is disabled). If the rules engine returns an email category with a threshold value but the threshold value is not high enough to meet the confidence value of any AMP rule associated with the category, the default category is used instead.

6. Processing for the structured email completes and the email is removed from the email queue.

You can access the email on the email workspace. Information about the email appears according to the field mapping of the webform template definition.