Skip to main content

Modeling Signature Flows

Goals

  • Understand what electronic signatures are and when to use them.

  • Know how to create new Signature Flows.

  • Know how to add a Signature Flow to a Protocol.

Key Terms

Table 15. 

Term

Description

Approval

Required signature that resets if data is modified.

Confirmation

Optional signature that does not reset if data is modified.

Signature Flow

Configurable signature queues for approval or rejection.



Note

Signature Flows can be configured to behave as an approval or rejection, and should be used in favor of these two (2) mechanisms moving forward.

Electronic Signatures in L7|ESP

Users enter their L7|ESP username and password to record their approval or rejection. Congruent with the action, an approve or reject reason must be selected, with the option to record additional comments.

Note

The signer does not have to be the logged-in user.

lims_signature_flow_modal_3_3.png
lims_executed_signature_flow_3_3.png

Note

Completed signatures record the reason, username, and date time of the signature, making them 21 CFR Part 11 compliant.

How to create new Signature Flows

Go to: L7|Master -> Signature Flow -> + New Signature Flow

master_signature_flow_details_3_3.png

Signature Flow details:

  • Name – name of the Signature Flow.

  • Description – description of the Signature Flow.

  • Tags – keywords associated with the Signature Flow, can be used to search or reference the Signature Flow.

  • Allow Asynchronous – users can sign stages that are not dependent on a nomination in any order.

  • Enforce Uniqueness – a different user must sign each stage of the Signature Flow.

    • This setting trumps individual settings for each signature (stage) in the Signature Flow.

  • Signatures – read-only field displaying the total number of signatures (stages) in the Signature Flow.

  • Accept Reasons – list of reasons the user can select from to indicate why they are providing a signature of approval.

  • Reject Reasons – list of reasons the user can select from to indicate why they are providing a signature of rejection.

Note

The same accept or reject reason can be selected more than once.

Once rejected, the Signature Flow is locked. If any of the signatures in the Signature Flow are required/block forward progress until signed, the user will not be able to complete the Protocol.

  • Version – saved changes create a new version of the Signature Flow, which can be pinned with a unique name.

Signatures

When building a Signature Flow, each signature is depicted as a card with configurable settings. Drag and drop signature cards to change the order of signatures.

master_signature_details_3_3.png

Signature details:

  • Type – who will be performing the signature, configured by Owner, User, Role, or Workgroup.

    • Owner is the owner of the LIMS Worksheet.

Note

The Nominated by previous signer option is available after the first signature.

Nomination is required unless the signature is optional.

  • Description – description of the signature.

  • Advanced (optional) settings:

    • Signature is optional – only available if nominated by previous signer.

    • Allow self nomination – only available if nominated by previous signer.

      • Self nomination is always enabled in L7 LIMS, it cannot be disabled.

    • Label – button label in the LIMS Worksheet for each stage of the Signature Flow.

    • ID – fixed value used to reference the signature.

    • Block process progress until signed – signature is required to complete the Protocol.

    • Data modification policy – defines the interplay between the signature and the data being approved or rejected; options include: allow data change, re-sign on data change, and signature locks data.

How to add a Signature Flow to a Protocol

Signature Flows are added to Protocols using the approval field type.

master_approval_field_parameters_3_3.png

Signature Flows can be configured to auto-complete the Protocol:

  • Never

  • Once all progress-blocking signatures are complete

  • Once all signatures are complete

Note

Auto-completion requires the Signature Flow to be the last field in the Protocol.