Filter conversations Rules and impact analysis with certain case scenario

  While loading an inbox stream, we follow following criteria: 

1. System should display all unhandled conversations come within specific date range 

2. If a conversation is done before and a new communication come in inbox, system should display it 

3. If a conversation is in assigned or in follow-up status and a new communication come in inbox, System should not display in stream. 

To comply all criteria's, we follow below steps: 

1. Get first 20 conversations with pagination 

2. Check date range and remove conversations if not fall in specific date range 

3. Get all saved tickets handled in last 2 months for these posts (* Performance Impact –1 detail has been explained later)  

4. Run an iteration of conversations and apply filter with following criteria 

   1. Check Page reply filtering enabled or not, if enabled, remove the conversations 

   2. Check Last message id of the done conversations, if new communication doesn’t match with last message id, keep it in the list else discard. 

   3. Remove all the conversations that already a ticket 

5. if no tickatable conversation found, then check conversations with next pagination and follow steps 1 –4 again (* Performance Impact - 2) 

6. If tickatable data found return conversation data and display  

 Performance analysis of considering last 2 months Tickets in filter stream 

Our tool has a policy that, we will show last 2 months data to our client. So if any communication comes within this period and not handled, it will consider as ticket-able. Otherwise we will not consider it. 

 User can choose any date range like  

• Last 7 days  

• Last 15 days 

• Last 30 days 

• Last 60 days 

• Custom range within last 60 days 

Currently considering last 60 days ticket data, impacting system performance. So we should reconsider it. Lets assume following case scenario’s: 

Case 1: user chose last 15 days data and start handling 

At first there will not be any ticket so all communication will come in stream and ticket date will be today’s date. 

Next day, user chose yesterday’s data, considering user handled some communication yesterday,some are in assigned status. 

If we consider ticket range from start date to current date, case will pass the validation. 

Case 2: After 15 days, one new communication come today which already  in assigned/followup state. So this communication should not come in stream. If we consider start date I.e today, it will not fetch 15days earlier assigned ticket hence communication will be count as ticketable so duplicate ticket scenario will arise in this case.  

So here we see that if any new communication of user with assigned/followup state came, system will allow to display in stream if we consider selected start date. And also 7 days /15 days value will not resolve the duplicate scenario. So 60 days filter is needed to comply our business rules 

1.  Proposed Decision is, keep the current business rule to avoid duplicate stream scenario.