Quick question - emailing new attribute values

Question

Hi - v. quick question.

I have an automated action (scheduled task in this instance) that updates a attribute values (custom Adaxes attribute in this instance) that then sends an email containing whatwas intended to be the new value. However, when this email is sent, even though it is *after* the attribute is updated, it contains the old value.

I can get an email sent with the new value by having a seperate business rule that triggers 'on change' of object, which works OK, but I'm just checking this is the expected behaviour i.e. that serial actions sets only see the 'on trigger' state of the object (this makes sense programatically but just want to make sure).

Regards

Answer 1

Hello,

The thing is that when you use value references (like %department%, %username%, or %adm-CustomAttributeText1%) in a Scheduled Task action, they are resolved all at once for the whole Task. That is, before executing a Scheduled Task on a specific object, Adaxes collects all value references that the Task uses and resolves them into their actual values. It is only then that Adaxes starts performing the actions defined by the Task.

What I suggest in your case is that you send the email message with a script using with the Run a program or PowerShell script action. To get a property of an object in your script, you can use the Get method of the IADs interface that is exposed by any directory object. Take a look at the description of the IADs interface for information and examples on how to use this method. For information on how to send emails from PowerShell scripts, see Sending Emails and SMS

Comments

Hi - this works as instructed.

Many Thanks

---

FYI We've worked out how we can suppress the original - non-customised - approval requests. We're probably not going to do it as it's a bit too much work and the benefit isn't huge, but in case anyone is reading this and saying "I wsh I could"...!

> Create a 'sinkhole' user account etc that is defined as the approver for all such requests, so the emails are sent but never received by end-users.

> Create another adaxes job that runs after the initial job that connects to the approval database, adds the target users' manager as an approver, deletes the original 'sinkhole' approver, then sends them a custom email to 'start' the process.

Like I've said previously about Adaxes - there's always a way if you look hard enough!

---

Hello,

Thanks for the update. Your active participation on this forum is really appreciated! ;)

---

Quick update/feedback.

Using the scripts\commands discussed in this thread we have identified a possible 'chase' condition.

It looks as if, if someone approves a request, there is a short window where the review is not marked as pending anymore, but the subsequent actions have not yet been completed. If the second task that detects 'denied' reviews is running at the same time it is possible that it can incorrectly trigger.

The 'follow on' actions in the original approval task (in our case anyway) overwrite the attribute changes that the 'denied approval detection' task make within seconds, although (again in our case) an email is sent to the manager saying the user has been marked for removal.

We thought this *may* be possible but was unlikely - but as luck would have it, it happened on one of our dry runs! In order to fix it we've tweaked the 'detection' task so that it actually has to fail twice, as below:-

This means the first time the check fails the user is marked (we use a timestamp as we've still got 5 free and don't want to 'waste' a Boolean\Text attribute!), and only if it triggers a second time does the actual 'meat' of the task trigger. The original approval task now also has a final action to clear the timestamp attribute also, so any 'half failed' accounts are cleared.

One general question that does come out of this (as we have halved the time repeat schedule so that a deletion is still detected within the same time window etc), do you have any advice on how regularily tasks such as this should run? This task is parsing through every user account, and every request etc, so would you recommend that we don't run these type of jobs *too* regularily?

It's not a problem, but good background so that we make sure we don't start stressing the processing engine by assuming we can just throw tasks at it etc.

Rgds

---

Hello,

Thanks for the update.

As for running Scheduled Task frequency, our general recommendation is to run Scheduled Tasks at night, when the load on Adaxes service and your network is minimal. This is even more applicable to your Tasks since almost each of them runs a PowerShell script, which involves creating the PowerShell runtime each time.