We just released a project simultaneously across three of our platforms (accountd¹, servicd, and stockd) that organizes a small, but important detail: when you send email from a toolset in the platform, where should the recipient's reply be directed?

For example, when you send a sales quote email from stockd, it includes your email text and a PDF attachment of the sales quote. The mail is sent from noreply@simplexable.com because we want to avoid being classified as spam.² What we want to avoid here is having the recipient(s) reply to an unusable address.

The simplest scenario (and now the default method) is to use a reply-to header with the sender's name and email address. Since we have recently updated all three of these platforms to use a single global service for the email interface, this was accomplished with just two lines of code.

This gets the job done. The email has a valid reply-to address, and a line is inserted into the content that indicates who sent it as well. What happens though if you want to standardize where the traffic is directed? That's the question we addressed in our latest release.

The goal for this design was to provide a single source of truth for the setup parameters using these principles:

In this default view, the user can see at a glance how the platforms are set up. In this company, billing (accountd) and inventory sales (stockd) use the same reply-to email address, but service management (stockd) uses another address. Unless this is changed, by an authorized user⁵, all email traffic will use these parameters. This simple design satisfies all three goals.

We added one more element though, to deal with the complexity of creating independent settings for multiple companies within the group. First, the +list control exposes the available parameters for each list, so the user can add, update or remove senders.

What we want to show you here is how Simplexable designs clean and simple interfaces to do powerful things like setting proper targeting for email interaction with your clients. The abstraction of the interface out to a global API that looks and works exactly the same in three independent platforms means a user can move from inventory to service to accounting, and feel comfortable due to a familiar environment. It also means maintenance and updates on our end are dramatically simpler as well.

This is a multiple-company capable accounting software, not yet publicly released.
The email is handled by Sendgrid using a DKIM authenticated sender. This sender has to be registered, and since we do not own the actual user's email address we can't use it here. That would be akin to email “spoofing” and trigger alarms on the email client.
accountd, servicd, and stockd. We can easily add more if the need arises.
This additional complexity arises from accountd, because it supports multiple companies inside a single accounting platform. The servicd and stockd platforms are single company.