Triggering Workflows on Error Details

The following describes how to trigger a workflow based on the specifics of errors in a run. For information on triggering a separate workflow for each error or for formatting error details into an email please see the OneDesign configuration document: 

https://softwareidm.app.box.com/v/a821/file/196919624675

Before creating a Workflow trigger off of MA runs or other run history, you should validate and test your rules using the rule engine tester in Settings -> Test and Recovery -> Rule Tester.

One way to trigger an error specific workflow is to inspect the DetailId property in the run history object. The Errors list contains references to detail objects, and these may be matched by Guid. If you have a specific error identified using the Identity Panel history page, you may open the detail popup to find the detail Id.

The following rule first filters to runs that had export errors, then finds a specific export error in the run result.

And(
  Counters.special.History Counter.Export Error > 0,
  MapOr(Errors, DetailId == "05da6afe-7f2f-5034-bbd5-7639ba668148")
)

Sometimes an error detail will contain text, such as the DN of a failing object that makes it unique per object. If this is the case, you will see the detail in the error text on the detail popup, or by finding it using the Rule Tester. A raw error detail object looks like this:

Another way to trigger a workflow (or lookup error details to embed in a workflow email), is to use the ErrorDetail(detailId) function.

The ErrorDetail function requires a database query to operate, so it should be used with care to avoid excessive iteration. The following example uses the Range function to make sure ErrorDetail will only be called at MOST 10 times.

And(
  Counters.special.History Counter.Export Error > 0,
  MapOr(Range(Errors, 0, 10), "invalid-dn" == ErrorDetail(DetailId).ErrorCode)
)

Note:

In the above rule, notice the order of the expression

"string" == Function().Prop

Instead of  the more normal

Function().Prop == "string"

This is because versions prior to 4.1 will have a Rule Engine parse error if a comparison operator follows a property lookup on a function result. One way to avoid this is to put the operator first. Another option is to wrap in parentheses. For example:

(Function().Prop) == "string"

After upgrading to version 4.x the workaround is no longer required.