Only way I know to test it to create an equivalent flow such as
Set up a new Membership Type - give a contact a membership of that type
Set up a Scheduled Reminder for above Membership Type
Set the Membership End Dates so that the Reminder would be scheduled for today
Run the Scheduled Reminders scheduled job
To clear and rerun find the entry created by ...
It might help to differentiate types of testing, e.g.
(User-oriented) Click-to-test/in-app test - This is the type of test supported in the CiviMail UI (which sends an example mailing). As dlobo points out, this type of test was not originally part of the scheduled reminder system, but it would be a great addition.
(Developer-oriented) Unit testing - For ...
I have made the same mistake myself, more than once - ugh! To avoid emails being sent when a scheduled job needs to catch up on backlog:
Switch from production to staging mode
Manually execute the schedule reminders job - this will result in an activity being recorded on the participant's contact record, but will not send the email (the desired impact)
You can use the "Limit to Recipients" along with a smart group to handle this.
Create a smart group of all members called "Receives Reminders".
Manually remove those folks who you don't want to receive reminders from the smart group.
Use the "Limit to Recipients" to only send to members of your smart group
I believe this is a bug and I have submitted an issue: https://issues.civicrm.org/jira/browse/CRM-17880.
Basically, if there is a previous entry in the civicrm_action_log (like from last year) with the same action_schedule_id (same reminder) no new reminder is sent.
The reminder will be sent when the next background Scheduled Reminder task is executed. I have the exact same situation and the reminder was sent by the Scheduled Reminder task 9 minutes later than the trigger because there was a large number of emails being sent. So you can't bank on it being sent immediately.
Is your Scheduled Jobs for Send Scheduled Reminders enabled at civicrm/admin/job?reset=1 ? If so, does the View Log Job have any info? /civicrm/admin/joblog?jid=8&reset=1.
If not, and if you want to confirm if your cron is running, then enable a Scheduled Job and then check back later, when it should have run, and see what the Scheduled Job shows as ...
Unfortunately I don't think testing was built into the scheduled reminder functionality. Seems like that aspect was just skipped.
I do think like contribution and event page registrations, having the ability to:
a. test the functionality and email deliverability of scheduled reminders, sending the emails to staff / tester rather than actual person
The main issue seems to be the <style> tag defined in the templates. Schedule Reminder uses smarty engine by default which strips down the css styles defined.
This doesn't occur in CiviMail because Smarty is disabled in civicrm.settings.php. If CIVICRM_MAIL_SMARTY is set to 1, civimail will too see this error.
As Smarty processing is done, escape the ...
A person once removed(not deleted) from smart group won't be added again back automatically if the contact's updates his/her information or membership. So schedule reminder will exclude the contacts that are removed from smart group.
Could be done with scheduled reminders
Adminster -> Communications -> Scheduled Reminders
Entity -> Event Name, choose first meeting name.
Repeat every 7 days until 10 years after event start date
(or something like that).
yes this can be problematic. You may also find that having other 'expired' memberships will trip you up when doing other searches etc. Therefore in a similar situation we have opted to find all the historic expired memberships and set them to a new Membership Status of 'previous expired'. that helped reduce confusion and would resolve your Scheduled Reminder ...
Multiple scheduled reminders are already possible out of the box using the "Scheduled Reminders" feature.
From the online book:
Creating and managing scheduled reminders
Scheduled reminders can be created from the administration page at Administer >
Communications > Schedule Reminders or during the creation of an
From the ...
When a membership is created there is both a 'join date' (member since) and a 'start date'
You should be able to set up a scheduled reminder to be triggered based on the 'join date' and you should get what you need.
This doesn't currently seem to be a feature available in CiviCRM, however, when setting up the schedule reminder, there is an option to "Record activity for automated email or SMS" - if this is toggled, then you can set up an activities dashlet on your dashboard filtered on the given activity such that every time you login to the back office you will see if ...
CiviRules + emailapi extension. Scheduled reminders is too inflexible as you can't control the criteria - with CiviRules you can build in whatever conditions you like.
Looks like you'd need to add a new "CRON trigger" to CiviRules for recurring contributions but we already have that for activities and for memberships so would be pretty easy to do ...
A contact is added to the list of scheduled reminder recipients when they first meets the criteria you have specified and the reminders will be re-sent to that list on your repetition schedule.
If you ran your scheduled reminder for the first time when your membership end date is in 3 days then it won't be on the reminders email list. Only memberships with ...
The issue you're seeing is because you must deselect the "auto renew options" text in the third input box. You can deselect with a Ctrl-click. I just tested on my 4.4.19 demo site and could save OK with that text deselected.
Thanks to @jaapjansma from CiviCoop for all his help and support. The issue has now been solved and merged into the main CiviRules development, if anyone is facing this issue, check out the fix and PR here.
As an answer (kind of) to the question:
I couldn't find a straightforward way to debug so, in this case the Reminder Sent or Membership Reminder sent ...
All (most?) activity types are exposed as options in scheduled reminders in 4.5 and 4.6. "Contribution" certainly is.
If you are still on 4.4 and don't want to upgrade yet then this forum topic may provide a way to do what you want.
The first one, process_membership, goes around and updates the membership statuses. It's what sets a member's status to "expired" once the end date comes around. Once upon a time, it sent reminders, but it doesn't anymore (new installations don't have that label for the job). You should be able to have it run daily.
The second one, send_reminder, is for ...
I think the reminders portion of the memberships has migrated to "Scheduled Reminders" but I believe the status update portion remains in the "Scheduled Jobs" area.
Once you get to 4.7 that warning about reminders is gone:
I do not think CiviCRM currently offers a way to catch bounced messages from sending an email direct from a contact record, or via Scheduled Reminders.
The only 'bounce' processing that occurs, afaik, is when CiviMail is used.
Not sure you'd class this as cunning or hacky but we have a trick & some code. Essentially we've changed scheduled reminders to send from CiviMail rather than triggering it's own one-shot emails. Workflow something like this
Set up a regular email in CiviMail complete with tracking
Send to a test group of internal emails
Set up your scheduled reminder, ...