Trying to setup custom From email address on "Send Email" smart service on Appian 19.2 ,19.3.
Got a reference to link https://docs.appian.com/suite/help/17.1/Configuring_Custom_Email_Senders.html#Adding_a_Custom_From_Address which is on 17.1
the paths of files has been changes for newer versions.
Can you please help in steps to create and new paths
below steps taken with reference to 17.1
Navigate to C:\appian\deployment\web.war\WEB-INF\conf\process\email-address-config.xml
created a copy of it as email-address-config-custom.xml (should the file be left in same locaiton?)
what is the next step?
link regered to one other file in C:\appian\deployment\web.war\WEB-INF\resources\text\jsp\WEB-INF\conf\process\email-address-config_en_US.properties
what should be done here?
Discussion posts and replies are publicly visible
Note that the 17.1 Custom Email Senders documentation you linked to above, will also come out as "on behalf of". The reply is returned to the correct "From" setting however. We've been using this internally for years, in the process of converting to the new in-node configuration as Tejas linked to.
However there's a specific difference with the new functionality that's impossible to override. It boils down to the fact that the "sender" header or similar (i'll have to look again to remember if this is the correct one or not), is forced to use the environment-specific "admin email address" when sending using the new setup. The prior custom sender workaround which we've also been using for 5 years in production, allows emails to be sent as if they're actually coming from the user account passed in. In our system this caused immediate failures because at least one of the mail handlers along the line rejected the apparent mismatch. If you examine the headers for the new way compared to the old way, it'll become immediately obvious what the difference is - and no resolution has been provided for this (again, "because security" or something.)
Interesting, in our environment the header information as well as "on behalf of" is the same across both old and new configuration methods. Just ran a test and compared headers, they match..
I'm wondering if your environment had the sender property modified in the email-address-config.xml file. We've always used the server email sender "bpm" in there, with the "From" as the address to be included "on behalf of".
<address name="serviceDesk" sender="bpm"> <expression>=cons!SERVICE_DESK_EMAIL</expression> </address>
Here are the exact header differences of note as per the support case I previously ran through Appian. Note that our previous solution was the customized sender option where the send email smart service required a user PV named "pv!fromUser" to be populated, to pull sender info from. I don't have any access to the configuration files involved since it's all on cloud, so I can't tell you exactly what the configuration looked like.
Pre-18.4 Functionality: - The "From" header appears as the email address for pv!fromUser - The "Return-Path" header appears as the email address for pv!fromUser - (There is no "Sender" header appended) 18.4+ Functionality: - The "From" header appears as the email address for pv!fromUser - The "Return-Path" header appears as the system notification email address - The "Sender" header appears as the system notification email address
Almost sounds like a customized custom sender - using the old config OOTB we never had the option to have dynamic/pv senders - only a constant that holds the email address. One HR solution with different emails per division (4) involved 4 custom sender configurations and a sub process with 4 matching email nodes, minus the sender changed per division on each.
Chris said:Almost sounds like a customized custom sender
exactly - at the start of the project i'm referring to (back in late 2012 or early 2013) the customer told us in no uncertain terms that emails were required to show up as if they were from the user who actually sent it from within the application, especially as many such recipients would be external users in external organizations / customer accounts, who wouldn't understand not being able to just click reply to an email. The solution that they put in place for us, actually shows the same "named" sender for anyone in the environment, but the reply-to address would be correct per the user in question. It's what we still use, as the OOTB 18.4 functionality was rendered basically useless by the "requirement" to set the "return-path" and "sender" as the system default notification email address (meaning it was apparently getting bounced by many external servers as this mismatch throws certain soft validation errors).