Skip to content

Create a Correction and Resubmission Loop

Goal

Return a reviewed request to its initiator for changes without starting a new process instance or losing the submitted form data.

What You Will Learn

  • route a review action back to an earlier user task
  • reuse the same process data when the request is corrected
  • require a correction note only on the return path
  • verify both approval and resubmission behavior

Difficulty and Estimated Time

  • Difficulty: Beginner
  • Estimated time: 20 minutes

Assumed Knowledge

You should be familiar with pools, user tasks, actions, routes, forms, and validation groups.

Required Reading

Prerequisites

  • permission to create or import a process definition
  • a test user or group that can be assigned to the Reviewer role
  • two test identities if you want to verify requester and reviewer ownership separately

Example Overview

The example contains three tasks:

1
2
3
Submit Request ──Submit──> Review Request ──Approve──> Complete Request
      ^                         │
      └────Request Correction───┘

All tasks use the same Request process data. Returning to Submit Request reopens the same instance, so the description and correction note remain available.

Steps

Create the Process Flow

  1. Create a pool named Correction Loop.
  2. Add the initiating task Submit Request with a Submit action.
  3. Route Submit to a second user task named Review Request.
  4. Add Approve and Request Correction actions to the review task.
  5. Route Approve to Complete Request.
  6. Route Request Correction back to Submit Request.

The return route is the correction loop. It does not create a child process or copy the process XML.

Configure the Reviewer Role

  1. Create a role named Reviewer.
  2. Assign a test user or group through the role editor.
  3. Assign the role to Review Request.

The downloadable definition intentionally contains no fixed identity. Configure the role after import so the example remains portable between domains.

Build the Shared Form

Create a form with two fields under the Request root element:

  • Description — required by the Submit validation group
  • CorrectionNote — required by the Correction validation group

Assign the form to all three tasks.

Set the Form Section State by Task

Use the same named Request section for all three tasks. Keep it in the default editable state on Submit Request, and set it to Disabled on the review and completion tasks. This keeps one data model and one form while making ownership of edits explicit at each workflow step. Use Hidden only when the user must not see the section at all; hiding a field is not an authorization control.

Connect Validation to Actions

  1. Set the Submit action validation group to Submit.
  2. Set the Request Correction action validation group to Correction.
  3. Leave Approve without a correction-note requirement.

This makes the request description mandatory when the initiator submits and the correction note mandatory only when the reviewer returns the request.

How It Works

A route can target a task that has already completed. The workflow creates a new work item for that task while keeping the same process instance and XML data. The initiator receives the request again because the target is the initiating task. After resubmission, the normal Submit route creates a new review work item.

The reviewer is resolved through a role rather than a hard-coded user ID. This preserves tenant portability and allows the assignment policy to change without modifying the task graph.

Verify the Result

  1. Configure the Reviewer role for a test identity.
  2. Start the process and enter a request description.
  3. Select Submit and confirm that Review Request is assigned to the reviewer and the request section is read-only.
  4. Enter a correction note and select Request Correction.
  5. Confirm that Submit Request returns to the initiator with both fields preserved and editable.
  6. Update the description and submit again.
  7. Approve the second review and complete the final task.

Failure and Edge Cases

  • Try Submit without a description. The form should fail the Submit validation group.
  • Try Request Correction without a correction note. The form should fail the Correction validation group.
  • Test with an unconfigured Reviewer role. The review task must not silently route to an unintended identity; configure the role before using the example.
  • Submit the correction more than once and confirm that each cycle preserves one process instance rather than creating duplicate instances.

Security and Portability Notes

  • The example contains no user, group, tenant, email, or domain identifier.
  • Configure Reviewer independently in each target domain.
  • Role assignment controls who can open the review task; form visibility is not an authorization boundary.
  • Add server-side route or postwork validation if a production rule must not rely only on form validation.

Download and Try It Yourself

Download the correction-loop process definition.

Configure the Reviewer role after import.

Troubleshooting

  • The review task has no owner: Open the role editor and assign a test user or group to Reviewer.
  • The correction note is not required: Confirm that the field uses validation group Correction and that the Request Correction action selects the same group.
  • The form data appears empty after returning: Confirm that all tasks use the same pool root and form data paths.
  • A new process instance is created: Confirm that the action uses a route to Submit Request, not a subworkflow or initiation script.

What to Learn Next