Flush the email with unread message summary and send a separate email notification for money requests

[anmurali]

Context here Summarizing what we want with email notifications for money requests:

• We want to continue to notify the user immediately via email when they receive a money request

• We want to use a subject line for this notification, which is different from the report title so as to make it cleaner, more legitimate and more appealing to the receiver

• We will update NotifyOfflineUsersAboutActivity to recognize when someone sends a money request -- and in that case:

  1. Set a custom subject
  2. Insert HTML formatted to mimic what it looks like in chat (being reworked in https://github.com/Expensify/Expensify/issues/364323)
  3. Make the CTAs automatically bring the user logged in to the action, which is handled here
  4. Send that one comment by itself as a nicely stylized, custom formatted, immediately delivered email that you can still reply to and otherwise functions just like any other comment notification

• We want this subj line to be satisfying, i.e. it should ideally say who is asking you, and how much they are asking for. So in this case, the custom subject line will read <Sender> requests <currency><amount>

• Sender - Use first and last name if available or fall back to sender's email/ SMS login info

NOTE: Here is the last solution we agreed upon.

[melvin-bot[bot]]

Triggered auto assignment to @shawnborton (Design), see these Stack Overflow questions for more details.

[anmurali]

I will work on mocking this up first with @shawnborton and then we can apply the engineering label

[shawnborton]

Not overdue, on my plate for this week.

[shawnborton]

@anmurali is there any more context that you are planning to provide before I dig it? Just responding to your comment "I will work on mocking this up first"

[anmurali]

@shawnborton sorry I have not had a chance to jump in here since last week but I will provide more context on this tomorrow. This is also categorized as Low, so I am going to switch it to a Weekly

[shawnborton]

Sounds good, just keep me posted!

[anmurali]

Ok, so the scope of this issue is just to refactor the email notification that goes out when a money request is sent (DM or workspace chat).

This is what it looks like today

What we want to do is reuse the unreadMessage notification, specifically when custom subject lines are used.

This is what an email notification for a message that uses custom subject line looks like:

Chat view (Highlighted message):

Email view

To reuse this construct for money request notifications:

Title/ Subj: Sender requests $amount Use Sender first and last name if available, fall back to sender email or phone number if not available

Body: We want this to be HTML and look exactly like the money request in the DM

Footer: This message was sent from Expensify. You can reply directly to this message, or pay by clicking on the Pay button

@shawnborton can we mockup this email and how the money request will look using custom subj line in the chat itself?

[shawnborton]

and how the money request will look using custom subj line in the chat itself?

This part tripped me up a bit. Does this mean we'd be adding a custom subject line to every single money request in the app?

[shawnborton]

To get the conversation started though, here is a first stab at this:

• The email comes from Expensify (notifications@expensify.com)
• The body of the email looks pretty close to a chat with the actual chat UI
• Footer message included as you requested

We might also consider doing something like a small intro blurb to our emails, something like:

or even add more logo power:

Then we can get even crazier and consider how we might just group together multiple outstanding items that need your attention:

(relevant thread in Slack about that idea above here, cc @RobertLadue @LLPeckham)

[anmurali]

This part tripped me up a bit. Does this mean we'd be adding a custom subject line to every single money request in the app?

Yes, that's the idea. So maybe we should also add a mockup that shows how that looks in product?

Then we can get even crazier and consider how we might just group together multiple outstanding items that need your attention:

This will be the actual unread message summary. The custom subject line kicks off a realtime email notification of that specific message, which is the money request and nothing but the money request. But the general unread message summary, which is still sent when you're not active in the product would combine all the outstanding items (chats/ requests and everything else you missed)

I personally like the intro blurb without the logo power but if you look at the one with the logo power, it says Expensify so many times that it looks weird! What do you think @shawnborton

Speaking of intro blurb, should we also include a subtext to say what our product is/ does? Like Venmo does?

They have a lot, we needn't add ALL that - they do cause their MTLs require them to I think. But just a single sentence saying what our product is might be good? cc @GabiHExpensify

[shawnborton]

I really don't think we should start adding subject lines above money requests - it definitely makes that flow feel way heavier. I think it's fine if the email subject exists but a subject doesn't exist in the product flow. Curious if @Expensify/design has any thoughts here too.

[shawnborton]

I personally like the intro blurb without the logo power but if you look at the one with the logo power, it says Expensify so many times that it looks weird! What do you think @shawnborton

I agree with this in this particular case. So maybe something like this feels nicest?

Though I wonder if we want to see how all of this will interact with the work that Lindsey and Bob are doing with the combined daily summary? It feels like there is some overlap here.

[shawnborton]

Speaking of intro blurb, should we also include a subtext to say what our product is/ does? Like Venmo does?

I don't feel too strongly here, but I can see where this is beneficial for users who have never heard of Expensify before and are receiving a request for the first time. I wonder if we could detect that in the notification and add this blurb for when we send something to a user who has never interacted with Expensify before?

[dubielzyk-expensify]

I really don't think we should start adding subject lines above money requests - it definitely makes that flow feel way heavier. I think it's fine if the email subject exists but a subject doesn't exist in the product flow. Curious if @Expensify/design has any thoughts here too.

I agree with this

[dannymcclain]

☝️ Same.

[anmurali]

Don't we NEED that custom subject line above the money request to leverage the custom subject line logic on unreadMessage summary? I am wondering if your design feedback effectively means back to the drawing board on the plan itself https://github.com/Expensify/App/issues/34167#issue-2072826021, especially 1 and 2?

[shawnborton]

Don't we NEED that custom subject line above the money request to leverage the custom subject line logic on unreadMessage summary?

Can't we just send whatever we want as an email subject? Like right now we are just choosing a subject that doesn't come from the chat messages right?

I am wondering if your design feedback effectively means back to the drawing board on the plan itself https://github.com/Expensify/App/issues/34167#issue-2072826021, especially 1 and 2?

I'm not entirely sure what you mean by this. I do think we can:

• make the email look more like the real chat, by including the preview card
• send whatever email subject we think is best in this particular case, even if the message itself doesn't have a subject

[anmurali]

Bringing this discussion to Slack here

[anmurali]

Ok based on that discussion above, I updated the issue description. Final mockup:

@MitchExpensify - I believe you will make sure this issue gets assigned to an engineer now?

[melvin-bot[bot]]

Auto-assigning issues to engineers is no longer supported. If you think this issue should receive engineering attention, please raise it in #whatsnext, and if it gets enough 👍, then please find a volunteer.

[shawnborton]

Sounds good. Do we want to first just make the email behave correctly in terms of text/content, and then follow up with style? Mostly just saying that in reference to David's comment here.

[MitchExpensify]

Sorry to take a step back but does this style of email exist yet? If not is it being introduced here or in another issue?

[shawnborton]

It does not exist yet.

So one approach could be to just make text-only adjustments for now, and then follow up and stylize all emails (per David's comment above)

[MitchExpensify]

So one approach could be to just make text-only adjustments for now, and then follow up and stylize all emails (per David's comment above)

This approach makes sense to me in that case. We should stylize all emails holistically as a first step - Checking if an issue exists for that project here

[MitchExpensify]

Tracking issue for stylizing emails here: https://github.com/Expensify/Expensify/issues/364323

[shawnborton]

Any update here @anmurali? Let me know if you need anything else from me!

[anmurali]

Just posted to the thread on this topic here but I don't see why we need to punt updating this email for style and wait for one catch all update. We should just update as we go.

[anmurali]

I updated the issue description to link out the appropriate issues to update the email body style and the CTA behavior. We can implement the rest in this issue. Makes sense @shawnborton and @MitchExpensify ?

[shawnborton]

Works for me, just let me know if you need anything else from me!

[anmurali]

I am going to unassign you. @MitchExpensify we need to get an engineer assigned to this. We do not need to hold it. We can assume the style changes and the CTA behavior will be handled in those separate issues I linked. We just need to make the rest of the changes here.

[MitchExpensify]

Cool, I'll hunt down a volunteer!

[francoisl]

Discussed in Slack, going to put this back in the pool to work on other wave issues. I'll grab it back if it gets no love when I have bandwidth.

[marcaaron]

I see that if I try to trigger this email locally I hit this block of code:

https://github.com/Expensify/Web-Expensify/blob/90a0948df54c48474cdb781a52d56d9bea004b72/lib/ReportUtils.php#L2569-L2572

@danieldoglas do you have any more context about that? I can disable it locally to get this email to send of course - but unclear whether all users would get moved onto this beta (I think the answer is that we are using it to add people e.g. testers as needed - but figured I'd ask).

[marcaaron]

Checked in on this question:

We want to continue to notify the user immediately via email when they receive a money request

Do we do this already today? If so, seems like we can remove this as a requirement. Sending this as a one off means we don’t have to worry about including other messages. Which makes things easier :+1:

And it looks like we don't send it immediately. So, that's the first thing to change here.

[marcaaron]

Left a few more questions here.

[danieldoglas]

(I think the answer is that we are using it to add people e.g. testers as needed - but figured I'd ask).

Yes, we were sending thousands of emails to a few non-used emails (like @expensify.anon) that were making the webrock cluster suffer during certain periods. So we removed those summary emails for them. Here's a bit of context if you're interested: https://expensify.slack.com/archives/C094TGUTZ/p1700331615222279

[marcaaron]

Makes sense thanks! I'm gonna disable those checks on DEBUG.

[marcaaron]

Ok basic logic for this is done (in the PR I have open) and the notification will look like this (for now):

And the CTA will redirect to NewDot instead of OldDot (like it was before). And also land the user in the parent report vs. the iou report or expense report view (that's where the "pay" button will be in the chat itself).

I'm going to push to get this merged and it should be easy to come back in with a second PR to hook up the styling. Which it sounds like @rlinoz is working on?

[rlinoz]

Huum yeah, I wasn't sure if I was supposed to include the styling for money requests in the issue I am working on, but I think this clarifies it.

[marcaaron]

Found an interesting edge case for this flow (unsure if we are working on it elsewhere):

Case 1:

1. Create a comment on an IOU report or Expense Report in NewDot
2. Wait for the notification to send
3. The email subject is the same as when we make a request - yet there are only comments inside (no requests):

It's also a bit weird if you do some combination of request + comments e.g. comment then request money...

Case 2:

1. Create a comment on an IOU report or Expense Report in NewDot
2. Request money on the same report
3. Wait for the notification to send
4. There is a mixture of comment and request line

---

For Case 1 - I think my expectations are that we'd send something that looks more like a report comment notification that just links to the report like this:

For Case 2 - I'm not sure? It feels like we should send one email with the comment summary and another for each individual request?

Does everyone agree with that (I can look into those tweaks now)? Or would we prefer to handle this as a separate issue?

[marcaaron]

Though, it does look like having the comments appear under the same email thread is the expected behavior based on the changes here cc @deetergp

[deetergp]

Yes, those changes were made as a part of the Teachers Unite campaign back in the fall. I don't think they're written in stone, so if something else makes makes more sense going forward, let's entertain it. But loop in @trjExpensify just in case.

[trjExpensify]

I haven't been following this issue, so might not be following its history or what's being asked fully, but..

If the proposal is to take any new request out of the "normal" unread summary email and send it as a standalone email with a custom subject header (that links to the parent chat not the expense report), then I would expect we don't also send the unread summary email for the expense report that the request was added to at the same time.

Outside of that, notifying about "unread" comments added to an expenseReport or an expense thread would be treated like normal:

• they use the report title seen in product as the subject line i.e Duraflame owes $50.00 (expense report), $25.00 request (expense thread).
• as a result they "thread" in the email client inbox just like any other chat/report
• it includes the comments they missed in the body of the email (one of which might be a request if they haven't read it since it was added to the report)

Apologies again if I've missed something or what was being asked here, coming in a lil' cold!

[marcaaron]

I would expect we don't also send the unread summary email for the expense report that the request was added to at the same time

@trjExpensify I think you are saying something like this...

• The emails should have the same subject so that threading works correctly
• If a request is made we will send a separate email immediately for that
• If a comment is made we would queue those up and then send them as a summary

In the case where a comment (or multiple) precede a money request we can send two emails. One for the summary and one for the money request. Everything should thread up in the same email chain.

[marcaaron]

That feels like what makes the most sense - as they will have different CTA links at the end of the day.

[trjExpensify]

The emails should have the same subject so that threading works correctly

Ah, not quite. I still think a request sends a custom subject email which is "standalone" from the unread messages email thread, we just don't double up and send an unread summary for that chat as well if there aren't any additional messages unread etc. Outside of that, I think we're on the same page:

Just a request:

1. UserA is offline
2. UserB sends a request to UserA
3. UserA gets a "custom subject email" with the request immediately
4. No additional "unread summary email" is sent ten minutes later

Request & messages:

1. UserA is offline
2. UserB sends a message to UserA
3. UserB sends a request to UserA
4. UserA gets a "custom subject email" with the request immediately
5. Ten mins later gets the normal "unread summary email" containing both any messages and requests unread in order

[marcaaron]

Ok, so we don’t care if the “unread summary” comes out of order? e.g. a comment that came before a request can appear in your inbox after the standalone request? That sounds fine to me, but want to make sure.

[marcaaron]

The only technical problem with that is that we have a single unique NotifyOfflineUsersAboutActivity job. So we can either:

• Create a new job for the IOU request email (not that hard, but more complex)
• Send only the "money request" action in the NotifyOfflineUsersAboutActivity job. Then queue another job for the comments later.

[marcaaron]

Heads up, I'm going OOO next week. For that reason - I'm gonna scale back these changes for now so that we are mainly only updating the subject line + sending the summary email immediately (which seems fine for now).

Here's what I think we need to do to achieve @trjExpensify's suggestion above:

1. Create a new job called SendReportActionNotification that can be used as a one-off similar to the "custom subject" job. I checked out the custom subject job and it doesn't feel quite right for this as we don't really have a "custom subject" at all. Maybe it can be used, but wasn't immediately obvious to me how and this feels like a different use case.
2. The new job will not be unique.
3. It will also not set the 'lastNotified user nvp (and not affect any already queued NotifyOfflineUsersAboutActivity jobs).

[trjExpensify]

Ah, interesting. I just stumbled across a convo related to https://github.com/Expensify/Expensify/issues/365156. @blimpich, are you already working on a solution to this issue?

Ok, so we don’t care if the “unread summary” comes out of order? e.g. a comment that came before a request can appear in your inbox after the standalone request? That sounds fine to me, but want to make sure.

To answer this though, it sounds like we do care and the proposed solution is to send the current batch of unread messages before the custom subject email.