none
Activity Execution Condition for entire workflow RRS feed

  • Question

  • Hi all.

    When I have a workflow with a number of activities and I only want this workflow to be executed if a certain condition is fulfilled, what is the best way to do that? I mean, I could simply put the condition in "Activity Execution Condition" for each and every activity in the workflow but I get the feeling there should be some better way to do it. Some way to simply abort the entire workflow if the condition isn't true. Some tips?

    /Daniel

    Thursday, June 8, 2017 8:48 AM

Answers

  • Define a set for objects with "true" values and craft your MPR to use that set as target definition for Request or Set Transition. Not firing the workflow is a better solution than having each activity in the workflow to evaluate execution condition (which is possible only for WAL activities, so if you have a mix of native activities this won't work). Individual activities cannot control the execution of entire workflow (and FIM WF parent/root activity does not allow it as well) so each activity must execute and decide for itself what it wants to do. So even if your WF is entirely using WAL activities there is no plan to change this behaviour and implement the WorkflowData temp variable solution that I mentioned in WAL activities. So you'll need to define AEC for each of them as you are currently doing or switch to the recommended MPR based solution.
    Monday, June 19, 2017 12:40 PM
    Owner

All replies

  • There is no other way currently than what you've already mentioned, but you can simplify by storing the results of AEC expression in a WorkflowData variable, say [//WorkflowData/WorkflowEC] in the first "Initialise" activity and using that WorkflowData variable as simplified AEC (ConvertToBoolean([//WorkflowData/WorkflowEC])) consistently in all remaining WF activities. I guess WAL activities can be coded to look for a specific Boolean variable name, but this is the first ask I'm hearing. I guess other people are simply crafting MPRs to ensure WF does not fire in the first place.
    Thursday, June 8, 2017 5:52 PM
    Owner
  • There is no other way currently than what you've already mentioned, but you can simplify by storing the results of AEC expression in a WorkflowData variable, say [//WorkflowData/WorkflowEC] in the first "Initialise" activity and using that WorkflowData variable as simplified AEC (ConvertToBoolean([//WorkflowData/WorkflowEC])) consistently in all remaining WF activities. I guess WAL activities can be coded to look for a specific Boolean variable name, but this is the first ask I'm hearing. I guess other people are simply crafting MPRs to ensure WF does not fire in the first place.

    Well, my MPR fires this workflow when an attribute is changed. Problem is I only want to run the workflow if the attribute is changed to true (and actually the last step of the workflow sets it back to false). So the condition is very simple (just ConvertToBoolean([//Target/attribute])) but it never feels good to put the same logic over and over again on multiple places :-)
    Friday, June 9, 2017 1:14 PM
  • You could configure the MPR to only trigger on "true" values.

    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!

    Monday, June 19, 2017 8:53 AM
  • You could configure the MPR to only trigger on "true" value.

    How do I do that?
    Monday, June 19, 2017 11:14 AM
  • Define a set for objects with "true" values and craft your MPR to use that set as target definition for Request or Set Transition. Not firing the workflow is a better solution than having each activity in the workflow to evaluate execution condition (which is possible only for WAL activities, so if you have a mix of native activities this won't work). Individual activities cannot control the execution of entire workflow (and FIM WF parent/root activity does not allow it as well) so each activity must execute and decide for itself what it wants to do. So even if your WF is entirely using WAL activities there is no plan to change this behaviour and implement the WorkflowData temp variable solution that I mentioned in WAL activities. So you'll need to define AEC for each of them as you are currently doing or switch to the recommended MPR based solution.
    Monday, June 19, 2017 12:40 PM
    Owner
  • Define a set for objects with "true" values and craft your MPR to use that set as target definition for Request or Set Transition.

    Ok, that might be the best solution. Seems many solutions in MIM ends up with me making another Set :-)

    /Daniel

    Tuesday, June 20, 2017 9:32 AM