Escalate to Manager - As Defined in AD

  • 4 December 2007
  • 8 replies
  • 4 views
T
Badge +9
I have created a very simple proof of concept client event that is meant to escalate to the activity to the destination user's manager after one minute.  To accomplish this, the destination of the activity is set to me (an AD user) and the escalation rule is set to be a redirect to ActivityInstanceDestination.User.Manager, which I assumed would be my manager which is defined in AD.  When I start this process, though, after one minute of sitting in my work list the process fails with this error:  'ActivityInstanceDestination property not available in the given context'.  Is there a better way to determine the activity's destination user from within an escalation rule, if Activity Instance Destination is not available?

8 replies

T
Badge +9
I have found a solution (I think), but I am still curious as to why what I attempted above did not work.  The solution was to set a data field equal to K2.ActivityInstanceDestination.User.Manager in a server event within the activity that gets escalated, and using that data field in the escalation rule.

 

J
Badge +8

I am getting this same error right now "ActivityInstanceDestination property not available on given context" but I am getting it on a line rule.  I have an InfoPath client event with two actions (approve and deny).  However I have added a third line that comes off the activity.  There are two paths the process can take when approved based on a field value in the InfoPath form.  I do want to have three actions appear to the user.


I have not figured out how to fix it yet.  I could add a dummy activity to resolve the problem but that defeats the whole purpose.


Any ideas???


Thanks,
Jason

G
Badge +4
Guys,

The default creation style for an activity in BP has changed from a 'plan per destination' to 'plan once'. I assume for this reason the ActivityInstanceDestination if not available. I've not confirmed this, but try the following to see if my suspicion is right. When on the destination rule, click back and then select 'Advanced wizard view'. On the Activity planning page, select 'Plan per destination - all at once'. This will force the workflow server to create an activity destination instance for each destination and put each activity instance in the context of the destination(s).

Note: You have to be aware of the result of planning per destination. For high performance systems where multiple users participate in an activity (i.e. call center style queuing), the performance impact of planning per destination should be considered.

Cheers,
Gabriel
J
Badge +8
I had thought about that too but it did not help.  I made the change and then I changed the line rules to use Process level XML nodes in the line rules.  So this makes sense because when the line rules are being evaluated after the activity event handlers have completed.
G
Badge +4

Strange.


Not note that when you have multiple activity instances, they are still available at the time of line rule execution. Not that this info is helping you with your problem. ;-)


Good luck, let us know if you've tapped danced around it.

S
Badge +1

Hi Jason,


 Did you manage to fix this problem when adding a third outcome manually?

J
Badge +8

Sorry, wish I could remember it, drawing a blank.... Jason

S
Badge +1

Hi Jason,


Just to let you know all you need to do to configure two actions with multiple outcomes is to change the Outcome detail from "All slots of Action Result = x" to "At least 1 of Action Result = x" and you should be good to go.


Hope that helps!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings