Catalytic is now PagerDuty Workflow Automation

Workflow: Reopen Task and Reset Dependent Tasks

note
  • Note: This action is no longer available, and has been replaced with the updated Looping Block. Existing Workflows using this action will continue to work as expected.

Use this action to enable looping back to an earlier state of the Workflow instance. This reopens an earlier task and sets all the dependent tasks back to a waiting status.

Use case

You can use this action if you need to redo or resubmit work after a review or rejection, like with invoice processing, or a legal contract review, where work must be redone and a change is needed.

Reopening and resetting dependent tasks can reset the automation, which is helpful for continued iterations on a document.

How to configure this action

Use this action to loop back and repeat segments of your process. To configure this action, choose the Task name to reopen. That task, and all dependent tasks, will begin again. For example, in an invoice review process:

  1. A vendor gets an Email: Send a form email to Submit an invoice. The invoice is processed through a series of steps.
  2. After processing, a PagerDuty Workflow Automation user gets a task to Approve or Deny an invoice.
    • If the invoice is approved, the process completes.
    • If the invoice is denied, this action will reset the Submit an invoice task and the vendor must submit a new invoice.
    screen readers look here
  3. Every task dependent on Submit an invoice is also reopened, and the invoice review process begins again. The PagerDuty Workflow Automation user can choose to Approve or Deny, which either completes the process or resets the process again.

💡   Tip: Whenever this action is used and a task is reopened, the original task is ended and the status is set to “Rejected”.

screen readers look here

For example, using the illustration above: once you reopen the “Submit an invoice” task, any earlier “Submit an invoice” tasks are set to “Rejected”.

How to set up a repeating loop with a counter

In some cases, it is useful to put a limit on the number of times this action can reset a task. For example, it may be necessary to reset a task, but no more than 3 times. A great way to set this limit is with a counter.

We can use a few PagerDuty Workflow Automation actions to create a counter that keeps track of how many times a section is reset, then configure this action to get skipped if the counter is greater than a certain number.

screen readers look here
  1. Add a Numbers: Perform basic math action before the task you wish to reset, in this example, Submit an invoice. Use the action to create a new counter field, and set the field to 0.

  2. Directly after Submit an invoice, use the Numbers: Perform basic math action to add 1 to the counter field. This raises the counter field by 1 every time it is reset.

  3. Set the conditions for the final task in the loop, Approve or Deny an invoice, so that if the fields.counter is less than X, it will continue to run. This way, once it’s greater than X, the task is skipped.

Fields for this action

  • Task name

    • Name of the task to be reopened, replacing all spaces and characters with a - and changing all characters to lowercase. For example, the task Input candidate information: would be input-candidate-information-
    • To quickly find the action name for a Workflow you’re working on, click on any action as if you were going to configure it, then click on the URL bar of your browser and copy the hyphenated string at the end of the URL after /steps/.
      screen readers look here
      The step name in this example is consolidate-report-for-manager which is at the end of the URL.
  • Mark complete if

    • This task will keep opening, causing the loop of actions to continue, until this condition is met. This configuration field is to be entered as javascript.

    • Please reference the Field: Field Formula article for more on javascript. This is an optional field.

  • Include optional

    • The default is true/blank, which will reopen all downstream tasks, even if optionally dependent on the task (using Start after any of these tasks are completed).
    • If false, those optionally dependent tasks will not reopen. This is an optional field.
    • 💡   Tip: An optionally dependent task is one that could be triggered by 1 of many tasks, using the Start after any of these tasks are completed dependency.

What will this output?

This action will reopen tasks and reset dependent tasks. There is no output other than the task status and work changing.

Get help with a problem or question

If something’s not working as expected, or you’re looking for suggestions, check through the options below.

Why are tasks being set to “Rejected” when I use this action?

Whenever this action is used and a task is reopened, the original task is ended and the status is set to “Rejected”.

screen readers look here

For example, once you reopen the task “Task A”, the following things happen:

  • A copy of Task A (we will call Task A2) and every task dependent on Task A is created. Task A2 is set to “In progress” and each dependent task is set to “Pending”.
  • Task A and every task dependent on task A are then set to “Rejected”, now that the duplicates are created and opened.
How is an infinite loop prevented?

Since this action could create a loop where it reopens itself infinitely, the action has two safeguards:

  1. If this action executes several times in a very short period of time, the system automatically applies a delay to the task which slows down the loop. This prevents slowing down other processes on the team.
  2. If this action executes 100 times, a manual task gets generated and assigned to the process owner to complete.

Tips

  • Conditions vs Mark complete if: Both fields essentially perform the same action, determining whether this action should be opened. In most cases, using Conditions will be ideal, as it is easiest to configure. However, there is one important distinction between the two which can be helpful for the build. If the Condition is not met, the action status will be skipped. However, when the Mark complete if condition is not met, the action status will be completed.

  • The field values entered throughout the instance prior to this action will remain, and the values can be adjusted when the actions are reopened. If you would like to create new fields each time the task is reopened, creating a subprocess may be a better option.

Sorry about that. What was the most unhelpful part?









Thanks for your feedback

We update the Help Center daily, so expect changes soon.

Link Copied

Paste this URL anywhere to link straight to the section.