E-Mail Triage NodeJS App Architecture

Objective:
Currently, customer team is spending more time in resolving the work items, which were created from each email received from the consumers (end customer).  To serve consumer quickly and better, the customer team want to optimize the work items creation by eliminating the categorizing the emails.
Hence, customer want to introduce a new system with the coloration of machine learning (ML) and existing software systems.
With the introduction of “E-Mail Triage App”, the volume of unsecure email handling would needs be reduced in the overall ecosystem of software systems. TIBCO invokes an API exposed by “E-Mail Triage App” to send the mail content.  The “E-Mail Triage App”, applies the identification logic and replies with the mail category. TIBCO creates the work item with appropriate status in the SFDC. 
 In addition, there is a twostep feedback loop a) feedback capture process and b) Learning process. 
 
Requirement – 01: Identification Logic
 
 

1. “E-Mail Triage App” would need to expose an API, which would be consumed by the current TIBCO system. Through this API, TIBCO would be sending the email extraction in JSON format with the following fields. (while architecting the solution , add the required fields , if required )  
   • From
   • Sent
   • To
   • Subject
   • Body

 The request and response format between TIBCO and E-Mail Triage App is attached in the forum. (TIBCO-E-Mail Triage App.txt )
Additional details about TIBCO process:
There are currently 5 mailboxes where emails are processed by TIBCO as a batch, in 15-minute intervals. The maximum amount of emails seen at one interval is approximately 50 emails. During the batch process, TIBCO will process the emails individually hence there will one request and response via “E-Mail Triage App” for each email. (Nevertheless, while architecting the solution, consider the best approach) TIBCO will retry “E-Mail Triage App” 3 times in the event of error. TIBCO will have a turn on/off mechanism to invoke the E-Mail Triage App. This is to ensure the existing process is not disrupted. 
Note: One or more TIBCO system may be available. Hence, one or more concurrent hit may occur for EMail Triage APP - APIs. 

1. After receiving the request from the TIBCO system, the new application would invoke the ML end point to identify the category of the email by passing the received JSON request.
   The identification will happen using Watson service Integration. It will respond back to TIBCO with
   1. the email category
   2. status of the work item,

          TIBCO creates the work item in the SFDC system. So that the customer team, only looks at the items that are marked with a status of 'Open'. 
         
   The request and response format between the E-Mail Triage App and Watson service is provided in forum. (first two in Watson.2.E-Mail Triage.Comm.txt )
   The process @ SFDC: (Feedback capture process)

The SFDC (Salesforce) system have a human intervention to verify whether the categorization done by the ML model / intents are as expected or not?  In case of,

• As expected, “Mark Thumbs Up” would be done and save to the SFDC.
• As not expected, “Mark Thumbs Down” would be done and required expectation would be noted and save to the SFDC.

 
Requirement: 02 (Feedback Learning process):

 
E-Mail Triage App will query the SFDC API to fetch the details, which would improve the ML model or intents. The fetched details would be given to the Watson Service.

The request format from the E-Mail Triage App to the Watson service is provided in forum. (3rd one in Watson.2.E-Mail Triage.Comm.txt ). 

Requirement: 03: Deduplication Logic
Continue processing by having TIBCO invokes the Dedupe API after creating the Work Item.
The Triage App will invoke SFDC API to find out if similar plan already exists based on the defined logic. 
For this logic the system is going to check if same plan holder exists on the system by verifying the following items with SFDC using API

• Originated from (broker name and email) - which will be extracted from the email-data
• Plan holder name, email and address - which will be extracted from the email-data

So if the same plan exists on SFDC system which is 6 month or less then its considered as duplicate.  
Note that the "Get Docs" step and the steps afterwards in the diagram below are out of scope. So if the broker is the same .... 


Note that the following items are out of scope: 

• Creation of Work item/record or related activities in SFDC
• Watson Assistant/Watson Studio development with Machine Learning (BR1)
• Any API development on TIBCO, SIMON, SFDC or Watson Studio
• User Interface development
• Updating the Watson ML (machine learning) model /indents for feedback

Security:
The REST API defined in E-Mail Triage App should support basic oauth.  

Integration:
You should document how the integration is done with the SFDC API and the Watson service (https://www.ibm.com/watson/developercloud/conversation/api/v1/node.html). Especically that if any security related to the SFDC API and Watson service should be properly documented. 


We will provide the API definition for the SFDC API and the Watson Service (check the files in the forum, for anything missing, please propose in your submission). The API endpoints for the SFDC API and Watson Service must be configurable as well.

Final Submission Guidelines

Deliverables:
Architect & Design document, which would consist of,

1. Architecture Diagram
2. High level solution design document
   1. API (swagger)
   2. Package
   3. Exception
   4. Back End design
   5. Logging
   6. Security
3. Assumptions
4. Constraints
5. Technology Stacks with the versions