Notification Meeting Notes

For the time being, for all notifications have it coppied to max and vish. Avoid using jargon in the emails make it as simple as possible in terms of the actions that they need to perform. 

For all output you can remove the jsons, include csvs unless otherwise stated. 

For any notifications that are going to be removed clean up the relevant portions of the codebase as well, but make sure you do not affect the functionality of anything that was kept in or adjusted when removing things for old notifictions. 

Todo for me: Still need to figure out the hosting. It should be run on the bumblebee server. Get suggestions from shetal and manan about where to host, probably an aws server. These should already be provisioned and shetal can give suggeestions and manan can prob give access. 

Todo for me: Need to get the separate mailbox for auto responder to use, cbi-automation, in the meantime once updates are finshed send vish and max a sample of the emails so that they can review and we can meet monday. 

The jist is that every email besides the audit log where actions are reuquired should have clear instructions what should be performed. 

 1.1/general notifications, output does not need to go to tarun, it should go to client services which is angel yogesh and cc matt, says this person is no longer there but they likely have active subscriptions. Make sure we are checking if they have any active subscriptions within the last 12 months or purchases within the last 12 months to the best of our ability and that all that information is forwarded on. The email should say the person is no longer available but this is the subscriptiosn they likely have and we should reach out to any new/related contacts regarding it. If a subscriber is not found in multipub tarun cannot do anything and he need not do anything. If the email is not found in mp in the databse. A separate output should be included for tarun when we are unable to determine the true email so that he can review the email bodies for those cases and see if there is an email for a subscriber that exists in multipub. If we can determine the sender email and we search multipub database there are two main conditions to be wary of. If they have an active order/subscription, have had a subscription in the last 12 months, or if they have a purchase within the last 12 months, then this should be in the notification to client services. Angel, yogesh, matt. In that email, clearly state that the auto responder process detected that these people are no longer available/retired/unreachable for these subscribers can you please reach out to these customers and make necessary adjustments, make sure to provide subscriber numbers for the emails. Send as attachment but also as a list in the email body. In the cases where you are unable to determine the sender email but have questions, that is what should be sent to tarun for review, tell him to feed it back to the endpoint which will trigger an email to client services basically saying the same as what is above. The endpoint should allow him to submit both a yes which triggers the notifcation with further changes and also a no which will create a log that the action has been taken care of and reviewed. 
 
 - For erin, the determinations for being there, deceased, retired, (inactive at their org) they should be suppressed from any future marketing efforts. That full list should be provided in a csv file and an email should go out to erin saying here is the list of people that the auto responder said are inactive can you please suppress them from your marketing communications. 

 1.4 Can be removed.

 1.5 So basically an email comes in saying you are no longer with the organization. ie susan is no longer available but she recently passed, for any client queries contact angel. Angel should be identified and the info should be sent to sai teja. He needs to find out of the person exists and if they are associated with the org. If they dont exist in cupola, then he will need to create the record and associate it in the org. What is in the body now should be good to go. And it should go to sai teja. Modify the subject line new replacements for inactive contacts. 

 1.6 Manual review for cupola things should be sent to sai teja for his team to take care of, the full audit log should be sent to venu. We want a way to get a report of what actions have been completed. We will expect a response probably in the form of an email notification back that the report has been completed. Make sure the subject line has something like action required and that instructions are included about how to review the records. The records should come in the body of the email and as a csv. 

 1.7 End of the run if there were any hodor prospect import rows. Gets sent to whoever is set for the hodor notification email, defaults to venu. Pretty much just an import file that is attached. It should be in the SAC import file format, make sure that is the case and ask me to clarify if not. 

 1.8 Unnecessary duplicatation can be removed clean up the codebase so that it does not get triggered

 1.9 Cupola undetermined rows, this one can be removed. 

 2.1 Full audit log/deliverables. Needs to be trimmed. Also need a better way of determining the metrics for the reports. Want to also see the dates and number of emails processed. Include something basically saying this is how many were complete, up to date x, and this is how many emails are pending 

 2.2 Impact summary for leadership, not currently required, but get the scaffolding going. It should be similar to 2.1, but with more detailed metrics and not the per record detail. No csvs included. But the metric like "records added" requires the verification of the manual actions that are taken by sai teja. This leadership summary will only be sent for each run when we have received a notification confirmation from all of the contacts that got a notification with action items. It should talk about how many new records were added how many orgs were added or updated. All the sort of information like that. Just about all of this is depending on Sai Tejas activities, so mainly we will need to wait for an email notification to come back to the mailbox that says the action items were taken care of and then the notification will be generated using that information and the information from the run. Or we can do it over api, whatever way is easier. Try using just the service mailbox incoming emails but. Orgs added. Records added. Corrections made. These are what we need from sai teja in order to generate the report. It should only be sent when all action items are complete

 2.3 The actual audit files for venu, can still cc sai teja, dont need to include json attachments just the csv outputs. 

 2.4 Human Review digest, contains more of the metadata type stuff, add to 2.3, cc max, remove otherwise. 

 2.5 The supression related item, this is the only thing that is required for marketing as discussed above, just the csvs none of the other stuff. 

 2.6 Tarun does not need multipub audit, remove 

 2.7 inactive notification for sai teja, combine into the previous one with action items. 

 2.8 remove