Accepted is not delivered.

The action completed, but no email followed

While repairing operational emails, I found production paths that recorded completion activity without calling the notification hook. Looking only at the activity log made the business action look complete, but said nothing about whether the email had been requested.

I added the notifier to the automatic completion paths inside the existing completion condition. Intermediate production updates still do not send a completion email.

The sender fallback missed an empty string

Another path did call Brevo, but supplied a blank sender. The fallback handled null and undefined, not an empty string. HTTP validation did not protect an internal caller passing configuration directly to the send service.

I normalized blank configuration, required the addresses needed at startup, and guarded the send service too. Tests check that a blank sender uses the configured default and that an explicit valid sender is preserved.

Business action completed
  -> Was the notifier called?
    -> Was the provider request valid?
      -> Did the provider accept it?
        -> Delivery still needs separate evidence

The test used only one person

A rejection handoff selected the user who had completed an earlier step instead of its assignee. That was wrong when an administrator acted on someone else's behalf.

The existing test supplied only the acting user. I changed the selection and added a test that distinguishes the assignee from the person clicking the button.

What the verification established

The repaired paths and regression cases establish which notifier runs, which sender is used, and who the intended recipient is. Provider acceptance was checked separately. None of that is an inbox-delivery rate or proof that a person read the message.

The linked demo lets you step through rejection, acceptance, a receipt, and a duplicate receipt using fictional data. It does not contact Brevo or reproduce the work system.