# Rules module Use the [Rules][1] module together with `Rules Scheduler` (a sub-module of it), as explained in the 3 steps below. These steps are based on a date field which is added to the user profile, so that for each user you can indicate an appropriate date. ### Step 1: Create a field to store the appointment date Add a field to the "user" entity with machine name (say) field_next_appointment. Allow only 1 date (the store the "next" appointment), but don't make it required. ### Step 2: Create a Rules "Component" Here is the Rules **Component** to be created (in Rules export format, just import it in your own environment via copy-paste): { "rules_send_email_notification" : { "LABEL" : "Send eMail notification", "PLUGIN" : "action set", "OWNER" : "rules", "REQUIRES" : [ "rules" ], "USES VARIABLES" : { "user_to_notify" : { "label" : "User to be notified", "type" : "user" } }, "ACTION SET" : [ { "mail" : { "to" : [ "user-to-notify:mail" ], "subject" : "Friendly reminder about your upcoming event", "message" : "This is a reminder about the upcoming event that you have an upcoming event on [user-to-notify:field_next_appointment] ...", "from" : "[site:mail]", "language" : [ "" ] } } ] } } Obviously, the ***Subject*** and ***Content*** of the eMail may need review / tuning, while you might also want to use some other ***From*** eMail ID. ### Step 3: Create a "Rule" using the Rules Component Here is the **Rule** to be created, in [Rules][1] export format (just import it in your own environment via copy-paste): { "rules_on_new_user_event_registration" : { "LABEL" : "On new user event registration", "PLUGIN" : "reaction rule", "OWNER" : "rules", "REQUIRES" : [ "rules", "rules_scheduler" ], "ON" : { "user_update" : [] }, "IF" : [ { "entity_has_field" : { "entity" : [ "account" ], "field" : "field_next_appointment" } } ], "DO" : [ { "schedule_delete" : { "component" : "rules_send_email_notification", "task" : "[account:name]" } }, { "schedule" : { "component" : "rules_send_email_notification", "date" : { "select" : "account:field-next-appointment", "date_offset" : { "value" : 259200 } }, "identifier" : "[account:name]", "param_user_to_notify" : [ "account" ] } } ] } } Note that the above rule refers to the *Rules Component* from the previous step. The `schedule_delete` that is part of this rule is to ensure that previously "scheduled" reminders will get removed when updating the data field (so that it only triggers 1 reminder, and with the most recent date). ### Step 4: Further tuning and enhancements - The ***date_offset*** (=259200) in the above rule corresponds to "3 days in advance", which may need review / tuning. - If needed, you could also use the [Field Permissions][2] module to set field-level permissions to edit, view and create fields on any entity. - Instead of just sending an eMail (as in the Rules Component), you could replace that by a more advanced option using the [Message][3] module (which has great integrations with the Rules module also). Here is an quote about that module (from its project page): > ... enables logging and displaying system events in a number of different use cases. Events that are recorded over time are sometimes call activity streams. Exportable messages subtypes can be created for different use cases with custom fields and display (view) modes. **Note**: [Using Rules to send an email X days after a user registers][4] also contains quite some details that may help you. # Date Reminder module There is also the [Date Reminder][5] module. Here is a quote about this module (from its project page, bold markup added here): > ... allows a registered **user to request an email** reminder to be sent at a specified time before an event. Generally these would be calendar events, but any **node** type that has a CCK datetime can support reminders. However I think that module is **not** going to answer your question, because: - it's the ***user*** who has to ***request*** such reminder (in your question ***you*** want to ***set*** a reminder to a specific user). - these reminders are related to some ***node***, while your question is related to a ***user***. You might possibly work around this by creating some extra node type (like "Appointment"?), though that seems like overhead. [1]: https://www.drupal.org/project/rules [2]: https://www.drupal.org/project/field_permissions [3]: https://www.drupal.org/project/message [4]: https://groups.drupal.org/node/62048 [5]: https://www.drupal.org/project/datereminder