How to Change Approvers or Emails After Approval Starts
Overview
This feature prevents bottlenecks in the approval process by allowing the user who started the approval (approval creator) to reassign an active or future User or Email step. When an originally assigned user is unavailable or an email address was entered incorrectly, the creator can dynamically update the assigned user or email without having to restart the entire approval workflow.
For instance, if an assigned approver unexpectedly leaves the company, the initiator can seamlessly swap them with a covering manager to keep the process moving. It also provides a quick fix for typo corrections; if an external stakeholder's email address was misspelled during the creation of the approval definition, the initiator can simply update the email step with the correct address instead of having to recreate the approval.
Delegation for Planned Absences
Alternatively, if a user knows they will be away, you can use the Delegation feature in the Global/Space settings to temporarily and automatically assign their approval rights to another user.
Identifying Inactive Users
To help you quickly identify bottlenecks in your process, the approval view provides visual indicators for users who are unable to make a decision. If an assigned user is no longer active or is unlicensed, their name will be visually distinguished on the approval step list (e.g., greyed out or displaying an "Inactive" or "Unlicensed" badge).
How to Enable Step Reassignment (Global Settings)
To use dynamic updates, the feature must first be enabled in the global configuration.
Navigate to Global Settings > General.
Locate the two toggles (enabled by default) and ensure they are checked:
Enable user steps updates: When enabled, approval creators can change assigned users in active and future User steps.
Enable email steps updates: When enabled, approval creators can change assigned email addresses in active and future Email steps.
Supported Step Types
Step Type | Editable via Approval Panel? (Hover & Click Name/Email) |
O (Supported) | |
O (Supported) | |
X (Not Supported) | |
X (Not Supported) |
Β
Requirements & Limitations
Permissions: Only the approval initiator can reassign a step. The creator must also retain the permission to start approvals.
Step Status: Reassignment is only available for Active and Future steps.
Voting Status: You cannot reassign a step if the current recipient has already submitted a real decision (e.g., approved or rejected).
How to Configure Reassignment (Definition Level)
Once enabled globally, you can control this behavior on a per-step basis within your step definitions.
Open the Step Definition Configuration for an User step or Email step.
Check
Allow change of the user (or email) during the processSave your configuration.
How to Reassign a User or Email during an Approval
If a step is configured to allow updates, the approval creator can make changes directly from the Approval panel inside the Confluence page view.
Hover over a reassignable step (active or future). The step will visually highlight to indicate it can be edited.
Click on the step:
For a User step: An asynchronous user picker opens. Search for and select the new user.
For an Email step: An inline text field replaces the preview. Type the new email address and submit (press Enter or blur focus).
Upon success, the approval view will refresh with the updated data, and a success flag will appear.
Possible Consequences & Warnings
Consider the following consequences and system behaviors:
Instant Notifications: Reassigning an approver instantly triggers a removal email to the previous approver and an assignment email to the new one.
Version & Audit Trail Inflation: Every reassignment automatically creates a new approval version. The change info (e.g., "Approver updated from Ellen to Paul") is permanently recorded.
Notifications & Version History
The system automatically handles communication and audit trails when a step is reassigned.
Notifications
Active Steps: The system sends an email notification to the previous recipient (informing them they have been removed from the step) and to the newly assigned recipient (informing them of their new assignment). If either the previous or newly assigned user has an active delegation, their designated delegates will also receive these notifications.
Notifications include the context (page), a link to the approval, and information about who made the change.
If a notification email fails to send, the reassignment still succeeds, and a warning message is displayed in the UI. Please note that there is no manual retry button to resend the notification. In such cases, the user who made the change should manually inform the new approver.
Activity Logs
Every successful reassignment creates a new approval version.
A clear change reason is recorded (e.g., "Approver updated from Alice to Bob by Charlie" or "Email updated from old@x.com to new@x.com by Charlie").
This change reason, along with the user who made the change, is permanently visible in the Version History and the Activity list for the approval, ensuring complete auditability.
@Parsa Shiva I went ahead and applied your APFJ feedback to the APFC document too