See https://support.esign-app.com for eSign Documentation and Support

Advanced Workflow Configuration

Contents

It is possible to integrate eSign with Jira workflows through advanced workflow configuration.

Workflow Validators

Required Signatures Validator

The eSign addon includes a custom workflow Validator that can be leveraged to control workflow. It can be used to require a certain number of signatures in the current status (or total) before a transition to the next status is allowed.

Add the eSign: Signatures Required validator in the desired transition using the Jira workflow editor:

Select the minimum number of signatures required and indicate if current status or any status. Also indicate if the condition should block issues with Pending Signatures.

User is a Signee Validator

This new validator will verify that the user transitioning the issue has already signed the issue in the current workflow state.

Void signatures or signatures from previous states will not pass.

Workflow Post Functions

Create Pending Signatures Post Function

This post function will initialize signatures on an issue and create 1 or more Pending Unassigned signatures. Use this to add clarity on what signatures are required for users.

This will also force the Signatures panel to display on an issue without any user pressing the Signatures quick add button.

 

Invite Users to Sign Post Function

Add this post-function to any workflow transition to send Invites to all users listed in a specific field (e.g. Approvers). The list of users can be set manually or via other Jira workflow functions and values.

Parameters

Example

 

Finalize Signatures Post Function

Add this post-function to any workflow transition to automatically finalized signatures. This function will also generate the PDF Signature archive if enabled for the project.

NOTE that eSign will require access to upload the attachment to the issue in the workflow state AFTER the transition.

Reopen Signatures Post Function

This post-function will reopen Signatures previously finalized (either manually or via the auto-finalized post-function).

Administrative Action (Cancel Pending/Void/Reset) Post Function

There is an optional post function that can be enabled in Jira to automatically revise signatures on an issue. The Void/Reset are typically used to in re-open type workflows where signatures need to be re-captured. To enable this, add the eSign: Administrative Action post function to the appropriate transition(s) in the workflow.

 

Signatures on Read-Only issues

For customers that want to lock down issues while they are in review/being signed, it is possible to customize the Jira workflow to accomplish this. Note that although the jira.issue.editable=false workflow status property will prevent editing of users, it also prevents the eSign app from saving Signatures, comments and attachments.

Instead, to prevent users from editing issues, but still allow the eSign app to accept and store signatures, use the jira.permissions.edit.* property setting in combination with the atlassian-addons-project-access project role.

 

See https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/ and this community posting for more information.
https://community.atlassian.com/t5/Jira-questions/Workflow-Properties-to-Only-Allow-quot-Automation-for-Jira-quot/qaq-p/1824439

Prevent Signature Changes on Closed Issues,

To sign an issue, the user must have view access to the issue and the issue must be editable (unless the Advanced Security option is enabled) and Signatures are still Open (not Finalized).

Once signatures are Finalized. Only a user with project admin (default security) or the administer signatures permission can reopen/change signatures.

It is possible to control which issue workflow states can allow Signatures via eSign Project Settings.

Post Function Processing - Note that Jira post-functions are processed AFTER the status of an issue is changed. jira.issue.editable=false will prevent eSign from uploading the PDF file if set on the issue state after the transition. Instead use the jira.permissions.edit.* property as described above to lock down issues.