Correct Returned Work and Resubmit

Act as the author after a reviewer requests changes. Use your own authenticated account with edit capability and policy resource access. The returned proposal remains editable, even when the interface labels it Rejected. An existing governed revision remains unchanged. Returned work is not yet a new submission. Save records corrections. Resubmission returns those corrections to In Review.

Before You Begin

Complete these prerequisites before correcting returned work:

• Obtain the policy identifier and correction request from the reviewer.
• Confirm edit capability and applicable owner/editor access.
• Keep the existing proposal. Do not create a replacement policy.

Correct the Proposal

To correct the returned proposal, follow these steps:

1. Open the policy identifier that the reviewer returned.
2. Read the reviewer’s reason in the available decision or history information.
3. Open the available edit or resume action. Policy reopens the existing proposal.
4. Correct the named title, classification, principal, method, or permission input.
5. Save the corrected draft.
6. Reopen the policy to verify the saved correction.

If your account cannot see the full reasoning, ask the reviewer for actionable feedback. Do not interpret a redacted or unavailable note as an empty decision. Do not create another policy merely to avoid the returned-work status.

Refer to Data Save or artificial intelligence (AI) preview and Save for lane-specific validation. If Save fails, preserve the current edits and visible error. For a connection or directory error, ask the administrator of the named integration to restore access before retrying Save.

Resubmit and Hand Off

To resubmit the corrected work, follow these steps:

1. Inspect current saved findings.
2. Correct hard failures or address permitted reviewable findings.
3. Follow submission using the current saved draft.
4. Confirm In Review.
5. Hand the same policy identifier back to the reviewer.

For direct application programming interface (API) use, obtain the current draft token. The server-issued draft entity tag (ETag), returned as Draft-ETag, identifies the current head for concurrency checks. Do not reuse a token from before the request for changes or later Save. Do not send another user’s name as the actor.

Verify the Handoff

History should retain the earlier request and the later resubmission. The reviewer must reload the submitted draft and review its corrected content before approval. If another user changed the draft, compare their changes with yours before saving again. Stop rather than overwriting unknown newer work.

Next, the reviewer follows review and approval. After approval, follow delivery.