Signature workflow for a legal request

  • Release version: Xanadu
  • Updated January 30, 2025
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Signature workflow for a legal request

    Contract Management Pro for Legal Service Delivery supports two types of signatures for contract requests: electronic signatures and wet (manual) signatures. This workflow enables you to manage contract signing processes efficiently, ensuring proper tracking, notifications, and document handling for legal contracts.

    Show full answer Show less

    Electronic Signature Workflow

    • The finalized contract document is sent electronically to signatories in a defined order based on the contract template rules.
    • Signatories receive email notifications with links to sign using configured electronic signature providers such as DocuSign or Adobe Acrobat Sign.
    • Signatories can either sign or decline the document. The system updates the signature status accordingly and moves the process to the next signatory.
    • When all signatories have signed, the signed contract is attached to the contract repository record, and the request status updates to Contract Signed.
    • If any signatory opts for a wet signature instead, the signed document is uploaded manually, statuses are updated, and the workflow continues with mixed signature types until completion.
    • If the document is declined, the requester is notified, and the contract status changes to Signing Declined. The document can be resent for signature after necessary updates.
    • A certificate of completion can be generated automatically if electronic signature is selected and the relevant system property is enabled.

    Wet Signature Workflow

    • The contract document is sent to signatories as a PDF attachment via email with instructions for manual signing.
    • The primary signatory is placed in the To field, with others in CC for visibility.
    • Signatories print, sign, and return the document to the requester. Multiple signatories may collaborate by signing collectively or individually.
    • If declined, the document is returned for correction. Signatories and contract fulfillers collaborate to finalize the document.
    • The contract fulfiller uploads the manually signed PDF to the system, which attaches it to the contract repository.
    • Contract request states update to Closed Complete and Contract Signed depending on contract type.

    Document Access and Management

    • Contract fulfillers can view and update contract documents.
    • Contract administrators have the exclusive right to delete contract documents.
    • Requesters can view only their submitted contract documents; users on the watch list have limited view access.
    • Data validation occurs when generating contract repository records. Any validation errors trigger email notifications to the contract fulfiller for correction.

    Additional Functionality

    • Upload manually signed contract documents to continue or complete the wet signature workflow.
    • Cancel wet signature processes from the Employee Center and cancel signature processes from the Legal Counsel Center as needed.
    • Supports contract request management including change requests, document revisions, and resending for signatures.

    Contract Management Pro for Legal Service Delivery supports electronic signature or wet (manual) signature for a contract request.

    Electronic signature workflow

    • Send the finalized document to the signatories for signing.
      • The state and contract status updates to Awaiting Signature and the electronic signature flow is triggered as configured in Configure an e-signature provider.
      • An email notification that the contract document is available for signature is sent to the first signatory. The email contains a link to the contract document that the signatory can open and sign the document through the Docusign or Adobe Acrobat Sign electronic signature provider as configured in the electronic signature integration.

        The first signatory is the one whose Order value in the list of signatories is set the lowest in the contract template rule. For more information, see Configure contract template rules.

    • Signatories can sign or decline the contract document.
      Table 1. Signatory action on the contract document
      Signatories action Workflow
      All the signatories choose to do an electronic signature
      • First signatory signs the contract document

        If there is more than one signatory,the contract document is sent to the next signatory in the order.

        The status of the current signatory in the request updates from Pending Signature to Signed. The status of the next signatory updates from Not Started to Pending Signature.

      • After the last signatory has signed the document, the contract repository record is created and the signed document is attached to it.

        For contract requests containing multiple contract documents, the signed contract document is split into individual documents and attached to the contract repository record for the respective contract type.

        The state of the requests updates to Contract Signed.
      One or more signatories decide to do a wet signature
      • One or more signatories decided to do a wet signature instead of electronic signature.
      • The wet signed contract document in PDF format is shared with the contract fulfiller.
      • The contract fulfiller uploads the signed document, selects the signatories who have shared the wet signed contract document and proceeds with the signature process by sending the document to the next signatories.

        The status of the signatory in the request updates from Pending Signature to Signed. The status of the next signatory updates from Not Started to Pending Signature. The signature type is updated to Mixed signature after all the signatories have signed the document.

      • After the last signatory has signed the document, the contract repository record is automatically created and the signed document is attached to it.

        For contract requests containing multiple contract documents, the signed contract document is split into individual documents and attached to the contract repository record for the respective contract type.

        The state of the requests updates to Contract Signed.

      The document is declined by the signatory.

      		 An email notification that the signer has declined to sign the document is sent to the requester.

      The Signatory status in the request updates to Declined.

      The State changes to Work in progress and the Contract status changes to Signing Declined.
      The contract document is resent for signature.

      For contract request fulfilled by the contract user: A contract user can submit a change request. The contract fulfiller works on the change request and sends the updated document back to the contract requester. The updated contract document is sent for signature by the contract user.

      For contract request fulfilled by contract fulfiller: The contract fulfiller creates a document revision manually or by using regenerate option and resends the document for signature.

      If the system property sn_cm_core.enable_executed_contract_audit_certificate is set to true, the certificate of completion is generated and attached to the contract repository record.

    Wet signature workflow

    • Send the finalized document to the signatories for signing.
      • The state and contract status are updated to Awaiting signature.
      • An email notification is sent to the signatories and the contract documents are attached as PDFs in the email.

        The signatory with the lowest Order value in the list of signatories is the first signatory and is placed in the To field of the email. The other signatories are placed in the CC field.

    • Signatories accept or decline the document.
      Table 2. Signatory action on the contract document
      Signatories action Workflow
      The signatory accepts the document.
      • The signatory prints the contract document,signs it, and then returns it to the signature requester.
      • If there are multiple signatories for the contract, they can collaborate and send the signed document with everyone’s signature or individually sign and send it back to the signature requester.

      The document is declined by the signatory.

      		 The signatory sends the document back to the requester for necessary correction. The signatories and the contract fulfiller can collaborate and finalize the contract document.
      The contract fulfiller uploads the signed contract document.
      • On receiving the signed contract document, Contract fulfiller uploads the signed contract document in PDF format.
      • The contract document is added to the repository after it is uploaded.

      For self-served contracts, the state of the request updates to Closed complete and the contract status updates to Contract signed.

      For non-self-served contracts, the state of the request and the contract status updates to Contract signed. To close the contract request, select Close complete.

      For more information, see Upload a manually signed contract document.
    Access to a contract document is based on the following user roles and conditions:
    • A contract fulfiller can view and update contract documents
    • Only a contract administrator can delete contract documents.
    • Requesters can view only the contract documents for which they submitted the contract request.
    • Users added to the watch list can view only contract documents for contract requests they have added.

    While generating the contract repository record, mapped fields and their values are validated for data type and correctness. If validation errors are found, an email notification is sent to the contract fulfiller. The email also displays the list of fields that haven’t been copied into the final contract document and the link to the contract repository record. The fulfiller then opens the record using the link and corrects the values to resolve the validation errors.