You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In our organization, we use Listmonk's new multi-user features extensively and it is a game changer for us (thanks!), but we've encountered challenges with sender addresses during campaign creation.
Currently, the instance is limited to a single default sender address, which means any deviation requires manual entry into a text field.
This limitation has led to several practical issues. Team members frequently struggle to remember and correctly input sender addresses, sometimes omitting names or accidentally using incorrect email aliases. These inconsistencies not only create an unpleasant receiver experience but can also trigger authentication restrictions with email providers like AWS SES when addresses don't match pre-accredited configurations.
This is especially tedious, because the auth errors only occur once the campaign is sent and being paused, which makes the address field unchangable. Therefore you have to copy the campaign and restart with the correct address, which also leads to a non consistent campaign history.
Describe the solution you'd like
I'd like to propose implementing a more flexible sender address selection mechanism in the campaign creation interface. Specifically, I'd like to introduce a dropdown/text field hybrid that empowers users to either select from multiple predefined sender addresses or enter a custom address seamlessly.
This solution would allow each user to choose from a list of relevant, pre-approved sender addresses while maintaining the flexibility to input a new address when absolutely necessary. By doing so, we can significantly reduce human error, improve email sending consistency, and simplify the campaign creation process.
I am happy to try to work on this issue myself – but since I am a GO novice, I don't know if this isn't too complex.
The text was updated successfully, but these errors were encountered:
Yep, this is a useful feature to have. Make the From field in settings accept multiple-values, and then present that as an auto-fill form on the campaign form.
Is your feature request related to a problem? Please describe.
In our organization, we use Listmonk's new multi-user features extensively and it is a game changer for us (thanks!), but we've encountered challenges with sender addresses during campaign creation.
Currently, the instance is limited to a single default sender address, which means any deviation requires manual entry into a text field.
This limitation has led to several practical issues. Team members frequently struggle to remember and correctly input sender addresses, sometimes omitting names or accidentally using incorrect email aliases. These inconsistencies not only create an unpleasant receiver experience but can also trigger authentication restrictions with email providers like AWS SES when addresses don't match pre-accredited configurations.
This is especially tedious, because the auth errors only occur once the campaign is sent and being paused, which makes the address field unchangable. Therefore you have to copy the campaign and restart with the correct address, which also leads to a non consistent campaign history.
Describe the solution you'd like
I'd like to propose implementing a more flexible sender address selection mechanism in the campaign creation interface. Specifically, I'd like to introduce a dropdown/text field hybrid that empowers users to either select from multiple predefined sender addresses or enter a custom address seamlessly.
This solution would allow each user to choose from a list of relevant, pre-approved sender addresses while maintaining the flexibility to input a new address when absolutely necessary. By doing so, we can significantly reduce human error, improve email sending consistency, and simplify the campaign creation process.
I am happy to try to work on this issue myself – but since I am a GO novice, I don't know if this isn't too complex.
The text was updated successfully, but these errors were encountered: