CASE 05 / Product & systems
Fixing notifications that never sent.
A blank sender, a skipped completion hook, and the wrong recipient: three failures I traced in operational emails.
- THE PROJECT
- Communication integrations
- THE CONTEXT
- GreenFortune
- THE CHAPTER
- 2025 - Present
Original concept illustration, not a production screenshot. Internal product details are intentionally kept high-level.
COMPONENTS / RESPONSIBILITIES / SCOPE
How the parts fit together.
The parts I followed while debugging these emails. The other communication providers listed above have their own integrations; this is not a shared production pipeline for all of them.
01
Configuration
I normalized blank sender values and made required email configuration fail validation at startup.
- The boundary
- An empty string is not null or undefined, so the previous nullish fallback did not catch it.
- Implementation note
- I also guarded the send service because internal callers do not pass through the HTTP DTO.
02
Milestone completion
I added the missing notification call to the production auto-completion paths.
- The boundary
- Recording an activity entry did not mean the completed-hook had run.
- Implementation note
- The call stays inside the completion condition so intermediate updates do not send completion emails.
03
Recipient selection
I changed a rejection handoff to use the assigned user rather than whoever completed the earlier step.
- The boundary
- An administrator acting on someone's behalf is not necessarily the next task's owner.
- Implementation note
- The earlier test only supplied the acting user; the new case distinguishes the two people.
04
Email service
The sender tests inspect the request passed to Brevo, including an explicit sender and the blank-input fallback.
- The boundary
- A provider accepting a request is not proof that the recipient received or read it.
- Implementation note
- The portfolio demo's receipts are fictional. They are not delivery evidence for these work emails.
Conceptual responsibility map. Not a production deployment diagram or a screenshot.
01 / The problem.
A completed business action did not always produce its email. Service-request sends could reach Brevo with a blank sender. Some production-completion paths recorded activity without calling the notification hook. A rejection email could go to the person who clicked a button instead of the person assigned to the work.
02 / My role.
At GreenFortune I have integrated Brevo, Exotel, Smartflo, Plivo, MSG91, 2Factor, and AiSensy across different workflows. My broader work includes email, call, SMS, and WhatsApp adapters with authenticated, deduplicated delivery-receipt handling. The example here is narrower: a September 2026 backend repair in which I traced missing and misdirected emails through configuration, milestone handlers, and recipient selection.
- My contribution
- Sender validation, missing notification hooks, recipient corrections, and regression tests.
- Shared scope
- The providers listed here span my broader GreenFortune work, not one seven-provider pipeline.
- What changed
- The repaired paths use valid senders, call the expected notifier, and address the assigned user.
- Brevo
- Calls
- Exotel / Smartflo / Plivo
- SMS
- MSG91 / 2Factor
- AiSensy
03 / An empty string bypassed the fallback.
The sender fallback handled null and undefined, but not an empty string. Brevo rejected the resulting request. I normalized configuration values, rejected missing required addresses at startup, and guarded the send service for internal callers. The regression tests cover both a blank sender and a valid explicit sender.
04 / The activity log was not the notification.
Production could auto-complete through scanning or a manual update. Those paths wrote activity but did not call the completion notifier. I connected the notifier inside the existing completion condition, rather than sending after every update.
05 / The test did not distinguish two users.
A rejection handoff used whoever had completed the earlier step, not its assigned user. The existing test supplied only the acting user, so it could not reveal that distinction. I changed the recipient selection and added a case where an administrator acts for someone else.
06 / The result.
- Blank sender configuration no longer reaches the provider through the repaired path.
- Production auto-completion calls the notification hook, not only the activity log.
- Rejection follow-up goes to the assigned user rather than an administrator acting on their behalf.