FIM2010–Developing Temporal Email Reminders

I have been involved with a couple projects where clients have been asking for email reminders to be sent out by FIM. Sending out a message once or twice on a given set of circumstances (like a date range) is pretty straightforward. However, what if you want to send out those notifications daily from a period of say 30 days before an event (e.g., a pending password expiration) occurs?

Simple Method – One or Two Email Notifications Required

The simple method for one or two messages is to simply create a set with the two temporal ranges defined. An example of a set definition that has been defined to send two email notifications can be setup using the following criteria:

  • Select user that match any of the following conditions:
    • All of the following
      • Password Expiration is prior to 30 days from today.
      • Password Expiration is after 25 days from today.
    • All of the following
      • Password Expiration is prior to 15 days from today.
      • Password Expiration is priot to 10 days from today.

The appropriate workflow and set transition MPR also have to be created where the workflow sends the email and the set transition MPR will take action when the user transitions into the set. So that in the case above, there will be an email sent once between the 30 – 25 days till expiration and another sent 15 – 10 days from expiration.


  • I have found it to be a best practice to use a date range instead of a single point in time. This allows the system to be down for a day or two without sacrificing the temporal based workflow actually firing. In this case so long as the user transitions in sometime during the 5 day period, the email will be sent.
  • This could also be completed with two sets, two set transition MPRs and one workflow sending out the email. That said, to keep the system less overloaded with MPRs and such, I prefer to use the one set method.

Complex Method – Daily Email Reminders Required until Action Taken

This is the example I was mentioning before where an email is required every day until the user takes action (which in turn resets the date the temporal sets are calculating membership with).

For these cases, I like to set up a notification datetime attribute and set up a single temporal set against the value.

The notification date is when the notifications are supposed to start (for example, passwordLastSet – 30 days). This is set using a workflow that is triggered when a request MPR is fired because the passwordLastSet value is changed or created. (I’m using the Tools4FIM Function evaluator for this date manipulation).

The set that looks for the notifications is defined as:

  • Select user that match all of the following conditions:
    • Notification Date is prior to today.


Again, note that this scenario will continue to send notifications after the notification date until the end of time. A secondary criteria will limit this activity by simply adding another date that will stop the emails (for example the employee end date when the account expires).

The MPR and workflow are similar to the one used in the simple example as it is a “transition in” to the set for a trigger. However, there is an additional workflow activity added to the notification workflow itself which adds a day to the Notification date when the MPR is called. The addition of the 1 day to the notification date forces the user out of the set until the next day when the user will fall back into the set again. 

This entry was posted in Forefront Identity Manager 2010. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s