Configurable Signature Rejection Workflow
Summary
Currently, LibreSign allows a signer to digitally sign a document, but it is not possible to explicitly reject a signing request.
Many organizations require signers to be able to reject a signing request, optionally providing a justification, while allowing administrators to define how that rejection affects the signing workflow and which information becomes visible to other participants.
This issue proposes a configurable Signature Rejection Workflow that is disabled by default, preserving the current LibreSign behavior.
The initial implementation should use a global configuration. However, the architecture should be designed to allow future integration with Policies & Rules, enabling different organizations, groups or users to have different rejection behaviors.
Goals
- Preserve current LibreSign behavior by default.
- Allow signers to explicitly reject a signing request.
- Allow administrators to define optional or mandatory rejection comments.
- Respect privacy and compliance requirements by allowing administrators to configure the visibility of rejection information.
- Keep the implementation compatible with future Policies & Rules.
Functional Requirements
FR1 - Enable Signature Rejection
A new global setting should enable or disable the Signature Rejection Workflow.
Default:
When disabled:
- LibreSign behaves exactly as today.
- Only the Sign button is displayed.
- No additional workflow is introduced.
When enabled:
Will display the follow options:
☑ Allow rejection comments
☑ Require rejection comments
☑ Allow who reject to make the comment private
☑ Cancel workflow after rejection
☑ Make public the rejection status at who rejected on validation page. If disabled, the validation page will be disabled.
☑ Show rejection comment on validation page
FR2 - Signing Experience
When the feature is enabled, the signing page should display two primary actions:
Both actions should have equal prominence.
FR3 - Reject Dialog
Clicking Reject must never immediately reject the signing request.
Instead, LibreSign should display a confirmation dialog.
Example:
Reject signing request
Are you sure you want to reject this signing request?
This action cannot be undone.
Reason:
____________________________
____________________________
[ ] Make my reason private. Only who requested to sign will see.
[ Cancel ] [ Reject document ]
Buttons:
The rejection is only recorded after the signer explicitly confirms the action.
FR4.1 - Rejection Comment
Administrators should configure how rejection comments work.
Options:
- Disabled
- Optional
- Required
When enabled, the comment field should be displayed inside the rejection dialog.
If configured as required, rejection cannot proceed until the comment is provided.
FR4.2 - Allow signer to don't expose rejection comment
Administrators should configure if who reject the signature is able to choose if want to don't expose the rejection comment.
The signer will see a rejection field.
FR5 - Visibility Rules
Administrators should independently configure which rejection information becomes publicly visible.
Suggested options:
- Show rejection status.
- Show rejected signer.
- Show rejection comment.
Default behavior:
- None of this information is publicly visible.
This default favors privacy and compliance.
FR6 - Workflow After Rejection
Administrators should choose how the signing workflow behaves after a rejection.
Continue workflow
Remaining signers may continue signing.
This supports approval and voting scenarios where rejection is simply another possible outcome.
Cancel signing workflow
The signing workflow immediately stops.
Remaining signers can no longer sign the document.
The document itself continues to exist, but its signing workflow becomes closed.
FR7 - Pending Signers
If the signing workflow is cancelled:
Remaining signers should no longer be able to sign.
Instead of the signing interface, LibreSign should display the validation page with all signers and will see at the name of pending signers a friendly message such as:
John Doe: This signer is no longer allowed to sign.
A previous signer rejected the signature of this document and the rule of this document is to disable the pending signatures.
John Doe: the pending signer name.
The page should not expose rejection information unless administrator visibility settings explicitly allow it.
FR8 - Validation Page
The validation page should respect administrator visibility settings.
Depending on configuration, it may display:
- rejection status
- rejected signer
- rejection comment
By default, rejection information should not be publicly visible.
Users responsible for managing the signing request (the requester) should always have access to the complete rejection information.
FR9 - Administrative Interface
The document management interface should adapt to the workflow state.
When the workflow has been cancelled:
- reminder notifications should no longer be available (the admin don't will be able to send a reminder notification);
- actions that are no longer applicable should be disabled (as example: delete a signer);
- the interface should clearly indicate that the signing workflow has been closed.
If the workflow continues after rejection:
- rejection status should be visible;
- requesters should be able to inspect rejection details at validation page.
FR10 - Workflow Status
The signing workflow should have explicit states representing rejection.
Examples:
- Pending
- Signed
- Rejected
- Cancelled
These states should be consistently reflected across:
- backend
- frontend
- API
- validation page
FR11 - Audit Trail
Every rejection must be permanently recorded.
Suggested information:
- signer
- timestamp
- rejection comment
This information should remain available for auditing purposes.
FR12 - Activity Events
Rejecting a signing request should generate Activity events.
Activity:
- Signing request rejected.
Message to send:
- The signing request was canceled.
These events should follow the same Activity infrastructure already used by LibreSign.
FR13 - Internal Events
Rejecting a signing request should dispatch LibreSign events.
These events will allow future integrations, automation and possible webhook implementations without changing the rejection workflow.
FR14 - API
The API should expose rejection information.
Suggested information:
- workflow status
- rejection timestamp
- rejected signer
- rejection comment (respecting visibility rules)
The implementation details of the API are intentionally left open and may use dedicated endpoints or extend existing ones.
User Experience
Feature disabled
Signer sees:
Current LibreSign behavior.
Feature enabled
Signer sees:
Clicking Reject opens the rejection dialog.
If configured, the dialog also displays the rejection comment field.
Only after explicit confirmation is the rejection permanently recorded.
Future Integration
The first implementation uses a global configuration.
Future versions should allow these settings to be managed through Policies & Rules, enabling different organizations, departments or groups to define their own rejection workflow independently.
The implementation should avoid architectural decisions that would make this migration difficult.
Out of Scope
This issue does not include:
- undoing a rejection;
- allowing a rejected signer to sign later;
- editing rejection comments;
- Policy-based configuration (future work).
Configurable Signature Rejection Workflow
Summary
Currently, LibreSign allows a signer to digitally sign a document, but it is not possible to explicitly reject a signing request.
Many organizations require signers to be able to reject a signing request, optionally providing a justification, while allowing administrators to define how that rejection affects the signing workflow and which information becomes visible to other participants.
This issue proposes a configurable Signature Rejection Workflow that is disabled by default, preserving the current LibreSign behavior.
The initial implementation should use a global configuration. However, the architecture should be designed to allow future integration with Policies & Rules, enabling different organizations, groups or users to have different rejection behaviors.
Goals
Functional Requirements
FR1 - Enable Signature Rejection
A new global setting should enable or disable the Signature Rejection Workflow.
Default:
When disabled:
When enabled:
Will display the follow options:
☑ Allow rejection comments
☑ Cancel workflow after rejection
☑ Make public the rejection status at who rejected on validation page. If disabled, the validation page will be disabled.
FR2 - Signing Experience
When the feature is enabled, the signing page should display two primary actions:
Both actions should have equal prominence.
FR3 - Reject Dialog
Clicking Reject must never immediately reject the signing request.
Instead, LibreSign should display a confirmation dialog.
Example:
Buttons:
The rejection is only recorded after the signer explicitly confirms the action.
FR4.1 - Rejection Comment
Administrators should configure how rejection comments work.
Options:
When enabled, the comment field should be displayed inside the rejection dialog.
If configured as required, rejection cannot proceed until the comment is provided.
FR4.2 - Allow signer to don't expose rejection comment
Administrators should configure if who reject the signature is able to choose if want to don't expose the rejection comment.
The signer will see a rejection field.
FR5 - Visibility Rules
Administrators should independently configure which rejection information becomes publicly visible.
Suggested options:
Default behavior:
This default favors privacy and compliance.
FR6 - Workflow After Rejection
Administrators should choose how the signing workflow behaves after a rejection.
Continue workflow
Remaining signers may continue signing.
This supports approval and voting scenarios where rejection is simply another possible outcome.
Cancel signing workflow
The signing workflow immediately stops.
Remaining signers can no longer sign the document.
The document itself continues to exist, but its signing workflow becomes closed.
FR7 - Pending Signers
If the signing workflow is cancelled:
Remaining signers should no longer be able to sign.
Instead of the signing interface, LibreSign should display the validation page with all signers and will see at the name of pending signers a friendly message such as:
John Doe: the pending signer name.
The page should not expose rejection information unless administrator visibility settings explicitly allow it.
FR8 - Validation Page
The validation page should respect administrator visibility settings.
Depending on configuration, it may display:
By default, rejection information should not be publicly visible.
Users responsible for managing the signing request (the requester) should always have access to the complete rejection information.
FR9 - Administrative Interface
The document management interface should adapt to the workflow state.
When the workflow has been cancelled:
If the workflow continues after rejection:
FR10 - Workflow Status
The signing workflow should have explicit states representing rejection.
Examples:
These states should be consistently reflected across:
FR11 - Audit Trail
Every rejection must be permanently recorded.
Suggested information:
This information should remain available for auditing purposes.
FR12 - Activity Events
Rejecting a signing request should generate Activity events.
Activity:
Message to send:
These events should follow the same Activity infrastructure already used by LibreSign.
FR13 - Internal Events
Rejecting a signing request should dispatch LibreSign events.
These events will allow future integrations, automation and possible webhook implementations without changing the rejection workflow.
FR14 - API
The API should expose rejection information.
Suggested information:
The implementation details of the API are intentionally left open and may use dedicated endpoints or extend existing ones.
User Experience
Feature disabled
Signer sees:
Current LibreSign behavior.
Feature enabled
Signer sees:
Clicking Reject opens the rejection dialog.
If configured, the dialog also displays the rejection comment field.
Only after explicit confirmation is the rejection permanently recorded.
Future Integration
The first implementation uses a global configuration.
Future versions should allow these settings to be managed through Policies & Rules, enabling different organizations, departments or groups to define their own rejection workflow independently.
The implementation should avoid architectural decisions that would make this migration difficult.
Out of Scope
This issue does not include: