Global Enable/Disable Email Sending
When doing a lot of work on our member listings we don't necessarily want an email sent with every change. It's tedious and subject to error to disable email, make changes, then re-enable email again.
It would be so much simpler to just turn off email while we perform maintenance on our lists, then turn it on again.
:( Sorry to hear that Liz. This is exactly the type of thing we hope we can prevent in the future. Unfortunately we don't have this feature assigned to a release yet, but hearing these specific cases is really helpful for when start working on it.
I recently had to change the Member Fee on a few levels. Unbeknownst to me, this automatically switched on New Member Confirmation emails for those levels. Why? The checkbox for this isn’t even on the same screen as the Member Fee, so I didn't notice WA had made the change when I saved. We accidentally had an email go out to a new member that shouldn’t have gone out. It’s very frustrating because I had previously, very deliberately set those emails to not send.
There needs to be a way to globally disable email, without affecting each member's "Subscribed to Email" status. The import/export method only works if individual email preferences aren't already set and it's safe to blanket switch everyone to unsubscribed and then to subscribed.
We are using WA primarily as an internal database at the moment and will be phasing in member self-service. I want ZERO emails to be sent by the system, but a set of renewal invoices just slipped through the cracks. It's incredibly frustrating trying to find every single check box that needs to be unchecked to ensure nothing gets sent out. It's also frustrating that the default for new events, member levels, etc. is to send out the emails to members. A global switch to turn all system emails off would be immensely useful.
Allow us to disable all Event registration initiated emails globally, not just individually. We NEVER want this email to be sent.
Jane Severn commented
i'm just setting up our new website, and i've had a few bumps along the way. As an admin, I need to make changes to multiple records to get our site set up correctly (e.g. set up bundles, move from one membership level to another). I would like to be able to turn off automatic emails triggered when I've exported/changed/imported records. Please help!
It's too elaborated. Here I was discussing a simple options to switch all emails off.
We have no progress here yet, sorry.
Terrill Thompson commented
I see there was some very good discussion about this back in 2011, but I'm not seeing how it was ultimately resolved. Has this feature been implemented? If so, where can I find it?
We have a help page on the subject of controlling automatic emails: http://help.wildapricot.com/display/DOC/Controlling+the+delivery+of+automatic+emails . Maybe you can take a look at it and let us know what if anything is missing in terms of being able to turn off automatic emails.
Hi all -
I'm still working with setting up database and site settings on my new WA account and am not yet ready to "go live". However, I've already had a couple of instances where automatic emails have been sent to members when I altered membership settings, and I would like to prevent these until I'm ready to fully roll this out.
Is there a way I can turn off all automated emails until that time?
John Unsworth commented
Another vote from a new user of Wild Apricot: the ability to globally disable and the re-enable email would be a very useful feature as you are creating and adjusting new accounts imported from other systems. Has any progress been made on this feature since August?
If you open export file, there will be a column named "Subscribed to emails". You can set "No" to all contacts and import back the file (update only this column). This will switch off completely all emails for your contact database.
I have exactly this issue, and have sent out automated membership type alterations - extremely embarrassing. Grrr.
By disable email, do you mean export. delete email and re-import? Or is there another field?
Thx for you help...
Here's a scenario that I'm facing now: I am entering name and address information manually for a number of new contacts from an outside database that doesn't include email addresses (but for some of these names email addresses have been entered in Wild Apricot previously). We want to send these people a mailer via the US Post Office. In order to enter their postal addresses, I have to either convert them into members (which will result in their being sent an email indicating their membership has been confirmed) or I will have to create customized data fields for their address information (which will become redundant if and when they convert to members on their own). It would be nice if I could turn off email in this instance so these people won't falsely receive a message indicating they are now members when all I am doing is entering their address information.
The only workaround now is export/import (export, disable emails in the file and import back)
Robert Weis commented
I'm also trying to manualy "clean up" my contact list after an inital import to WA. I would really, really like to temporarily disable automatic emails to members when I change their memebr status (Sc-1 above). Is there a way to do this.
It is a real pain to disable each contact's email!
Re SC-03: I do not know yet, this was just a question for analysis :) But I got your point, thanks.
I think you've understood my wishes. Sc-02 is exactly what we're after.
Let me continue our dialog :)
Wild Apricot emails can be grouped like this:
* Automatic emails sent to account owner by WA - plan limit exceeded, etc.
* Self-service workflows emails (triggered by public visitor/member actions) - membership application pending, invoice, event registration pending...
* Manually sent emails - e.g. newsletters - by using Email button
* Automatic scheduled emails - i.e. event reminders, membership renewals notifications
* Email implicitly triggered by some administrator actions - there are currently very few, we removed membership application initiated in 4.3 - but still there are some.
We definitely cannot block group 1 - these are system emails for account owners only.
Importance of other 4 groups depends on scenarios:
* Sc-01: Prevent accidental emails during initial setup
* Sc-02: Testing system before going live
* Sc-03: Temporarily disable emails in live account
Sc-01: all 4 groups can be disabled completely. No public actions are expected (i.e. no membership applications or event registration) and admin can just completely disable them for some time.
Sc-02 is a variation of Sc-01 but here admin is interested in checking his setup and he probably wants to check emails. I think that ideal solution is to send emails BUT redirect them all to a single (test) email for review.
Sc-03 is a very different case: system is live and people can apply for membership, register for events, make donations, etc. If they do not receive their emails, that would break the whole workflow. So in this scenario we are probably speaking only about emails from group 4 and 5 only. Also, if any email was missed (i.e. renewal reminder was skipped) then admin should be able to see this somehow (in emails log?) or even be able to rerun it again when he is done with updates.
In any case, when normal email workflow is disabled, there should be a notice clearly visible in admin backend interface.
Does it make sense? Comments?
Dmitry Buterin commented
Again, just citing my own needs, I'd see it as most useful during the initial setup. I can't imagine we're the only ones going through our database and getting it cleaned up. In fact, today one of our volunteers accidently sent email to some members; the very thing I want to prevent.
Using it later would seem less likely on the assumption that the records are in good shape. Of course, adding a new field or two and populating them one by one might again make a global disable desirable. It would be up to the administrator to be aware of the potential of missed actions - unless you could (here I go again) take the whole database off line for mantenance.
As a heavy duty database user I'm spoiled by the ability to make sweeping changes.