I am seeking to implement an exception handling technique that, in the event of a failure in the initial set of actions within the automation workflow, will trigger alternative actions. These alternative actions will involve raising a ticket in ServiceNow, including all relevant details. This will ensure that an incident is created, and the person assigned to work on that incident will have sufficient information regarding the workflow failure. With this information, they can investigate the issue at the appropriate location
Question
Upon Workflow Failure performs different set of Actions
Unless Nintex can provide a better solution here are my two recommendations.
1) just use workflow instance alerts without creati g a service now ticket
2) if SN is needed. I do not believe error handling is available at present. You'd have to do a scheduled workflow to query failed workflow instances using nintex connector...the get workflow instances action. NOTE: you'd probably need to remove duplicates and probably check, if possible, if open tickets exist already for the particular workflow before creating a new SN ticket.
I tried responding this morning. Guess my post didn't go through.
Unless they can provide a better solution here are my suggestions:
1) create a scheduled workflow and use the get workflow instances action for only failed instances. You'd want to add workflow ID to a new collection after looping through all returned values and then remove duplicates then create a SN ticket for each workdlow ID unless you want a new ticket per failure for same workflow. You may want to check SN for open tickets against that workflow ID (or instance ID if on instance level)...wherever you may store it in SN in case you have to rerun instance for some reason. Id assume you wouldn't want it creating them again if they exist.
2) use instance alerts feature if you can live without SN tickets.
+16Hi
As
There are some critical building blocks to retrieve failed workflow instances - namely the NAC APIs and the NAC Connector.
Depending on your planning, you will need to periodically “poll” for the status of your workflow using a Scheduled Workflow.
Track the workflow status using a SP List or SQL or any other data structure. Record down the Workflow Instance ID and its Status. if the Workflow Instance has FAILED, do log when any action(s) has been taken.
Sample Table for Workflow Instances Tracking
| Workflow Instance ID | Status | Action Taken |
|---|---|---|
| 001 | Running | |
| 002 | Failed | Yes |
| 003 | Failed | No |
| 004 | Completed |
List of Valid Status
Hi
As
There are some critical building blocks to retrieve failed workflow instances - namely the NAC APIs and the NAC Connector.
Depending on your planning, you will need to periodically “poll” for the status of your workflow using a Scheduled Workflow.
Track the workflow status using a SP List or SQL or any other data structure. Record down the Workflow Instance ID and its Status. if the Workflow Instance has FAILED, do log when any action(s) has been taken.
Sample Table for Workflow Instances Tracking
| Workflow Instance ID | Status | Action Taken |
|---|---|---|
| 001 | Running | |
| 002 | Failed | Yes |
| 003 | Failed | No |
| 004 | Completed |
List of Valid Status
Hey hey that is great news! Lol
I'm reading your screenshot.
But will we be able to bypass error and move to next action? I don't think anyone will want to resolve all workflow failures. Some are due to other restrictions. So we'd need something that just allowed us to continue on with the next action if error for example contained xyz or something like that then do this, if not terminate workflow.
That way if we are expecting an error maybe we want to loop again to perform it over after pausing for an hour or something. I'm hoping for this behavior with that release, as it would resolve our issues eith library files being locked by user for shared use error because they have the file open when we try to update metadata.
+23- Nintex Employee
Hi
If you are expecting errors but want the workflow to continue you could put the actions that are expected to error into a component workflow and set it to run concurrently.
You then pause the parent workflow for a minute or two. Then query the item from the parent workflow to check if the component workflow (child) did the update. If it did not do the update you could pause for an hour and then loop again which runs the component workflow again etc.
It wont matter if the component workflow fails, the parent will keep running.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.