{"id":2539,"date":"2013-02-21T09:13:06","date_gmt":"2013-02-21T09:13:06","guid":{"rendered":"https:\/\/www.wapshere.com\/missmiis\/?p=2539"},"modified":"2013-02-21T09:13:06","modified_gmt":"2013-02-21T09:13:06","slug":"scheduled-notifications-from-the-fim-portal","status":"publish","type":"post","link":"https:\/\/www.wapshere.com\/missmiis\/scheduled-notifications-from-the-fim-portal","title":{"rendered":"Scheduled notifications from the FIM Portal"},"content":{"rendered":"

I was asked today to implement notification emails on changes to certain groups. Like many situations with the FIM Portal this turned out to be trickier than expected. A number of the groups are criteria-based so don’t actually have a member attribute as such. With no member-update request happening there’s nothing to actually trigger a notification workflow on.<\/p>\n

Fortunately the customer was happy to have a daily scheduled email with a summary of changes, rather than immediate emails on every change.\u00c2\u00a0So I took inspiration from Bob Bradley’s Housekeeping Policy<\/a> approach\u00c2\u00a0to solve\u00c2\u00a0the problem.<\/p>\n

<\/p>\n

ROPU Workflows<\/h2>\n

The first thing to know about is the “Run on policy update” workflow.<\/p>\n

\"\"<\/p>\n

When combined with a “Transition In” MPR this has the very useful effect of re-applying the policy to all members of the Transition In Set upon any change to the MPR.\u00c2\u00a0“Any change” includes\u00c2\u00a0enabling the MPR, so\u00c2\u00a0this is a simple way to force the policy to run against\u00c2\u00a0all the objects that are already in the set <\/em>– effectively re-running any Action workflows, such as a notification.<\/p>\n

So all I need to do is get an object in a set, make my ROPU workflow, then just toggle the Disabled switch off and on for the MPR when I want to fire the notification. Easy!<\/p>\n

Workflow Configuration<\/h2>\n

The first thing my workflow does is call the PowerShell activity<\/a> to gather the information I want to insert into the email. I format it as HTML and then pass it back to the workflow in a WorkflowData parameter.<\/p>\n

\"\"<\/p>\n

The Email Template then simply includes the WorkflowData parameter:<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Transition Set and MPR<\/h2>\n

Before I can create the MPR I need to create a set. It really doesn’t matter what is in the set in this example as I’m not using any values from the Target in the workflow, however I only want it to have one member so the notification only triggers once.\u00c2\u00a0For convenience I have the object receiving the notification as the member.\u00c2\u00a0(I expect I could extend this idea to include other objects needing notifications as well, though I’d need some logic matching set-members to their specific notification requirements.)<\/p>\n

The MPR is then very simple to set up:<\/p>\n