Workflow - Trigger notification if virtual attribute equals x

Hi,

I would like to create a workflow that triggers a notification when a specific attribute is set to a specific value.

We have created a custom attribute that will hold a specific value that we would like to monitor.

The workflow should work on a schedule that executes multiple times a day.

I created a the workflow and added the following pieces.

  • It is currently not scheduled, but will be scheduled to run hourly, every 4 hours
  • A "Search" that searches the specific virtual attribute for a value of "false"
    • A "Save object properties" that saves properties from the found objects
    • A "Notification rule" that uses the saved properties to then send a notification

    I am just curious if this is the correct way to go about doing something like this? Is there a more straight forward way? (I tried to update pictures but wasn't able to find a way to do so).

    I was also wondering, if I wanted to write a powershell script to handle the notification, is there a way to reference the objects retrieved from the search, then loop through them and then send off an email?

    This is pretty straight forward when doing it through scripts, but I am not sure how to access items from within a workflow.

    Any help, suggestions, or examples would be incredibly helpful!

    Cheers

    • Why would you want to schedule it? You should be able to act "live" once an attribute is changed. You might also want to check if ChangeAuditor maybe better suits your needs.

    • The more straightforward way would be to detect the change to the attribute as it occurs using a "change workflow".  The trigger for the change workflow is the attribute change itself.

      I have seen where this isn't practical sometimes due to timing issues - particularly when you are waiting for something to happen to an equivalent object in a cloud tenant for example but if all you really want to watch for is the change to the VA, then a change workflow should do the trick.

      The only other potential "gotcha" is around "who" is making the change (for example, a privileged service account) in which case you should specify that account in the "initiator" filter of your change workflow start condition.

    • With respect to referencing the object that is having the attribute set, the AR transaction ($Request) object offers a couple of different options for reading back the name of the object being affected by the change:

      # Distinguished name

      $Request.DN

      # samaccountname

      $Request.name