Solution options for mapping signer to multiple signature fields

Hi Ron,

It's great to hear from you!

If you are looking for the capability to add dynamic number of fields without knowing the number and the position of the signatures/fields, using Text Tags instead of Text Anchor could be your choice:

#1 Since you have the ability to add hidden text to the generated document

#2 You only need to add the same text tag across the whole document

Here I've attached an example word file where I added the same tag "{{esl:Ron:signature:size(200,40)}}" to the left bottom corner of each page. If you send the transaction with below payload, all signatures will be extracted automatically (Note the role name in the payload needs to match the name specified in the tag):
{
  "documents": [
    {
      "id": "sample-contract",
      "name": "Test Document",
      "extract": true,
      "extractionTypes": [
        "TEXT_TAGS"
      ]
    }
  ],
  "status": "DRAFT",
  "type": "PACKAGE",
  "roles": [
    {
      "id": "Ron",
      "type": "SIGNER",
      "signers": [
        {
          "email": "[email protected]",
          "firstName": "John",
          "lastName": "Smith",
          "id": "Ron"
        }
      ],
      "name": "Ron"
    }
  ],
  "name": "Text Tags Example Package"
}

Please let me know if this fits your requirement.

Duo

Thanks Duo for the information on this.  It appears the zip you attached was empty (22 bytes in size), but I think I get the idea here. For some reason though when I read about text tags I misunderstood, so I just want to confirm I understood you correctly now.  This is using text on the document and not pdf fields for its location, is that right? I am 99% sure that is what you are saying, but since I can't try it out myself at this second and it is important for this use case that it locates based on content on the PDF I just want to make sure.

So if I have a PDF template with a signature block, it sounds like if we were to render a string on top of it (or on top of multiple signature fields for that matter) with white text as follows:

{{esl:Signer1:signature:size(200,40)}}

Then OneSpan will place a signature field in each location provided we sent a signer with role of 'Signer1' in our API call. 

Is that correct?

Hi Ron,

What you described is exactly how Text Tags work. It's based on the text on the document, which is similar to the text anchor but with a certain syntax. And because you have already defined the field type, signer role, field size, etc. in the syntax, it saves the complexity of building the approvals and fields nodes in JSON.

Duo

Thanks Duo,

One last question for you.  Let's say we already have a process which uses anchor text values.  And lets say there are LOTS of signatures across LOTS of documents and that we have ensured all the anchor texts are unique and everything is working fine, functionally speaking.  If we were to convert this to the text tag solution, certainly our call into your API would be greatly simplified, but do you know if it would have any performance ramifications, good or bad?  We have found with other signing processes implemented at the bank using different technology stacks that certain types of positioning are (much) faster or (much) slower than others.  Can you comment on the differences pertaining to anchor vs text here?

Thanks again!

Hi Ron,

I am not an expert in document engine, but from the best of my knowledge, the internal workings and technologies being used between Text Tags and Text Anchor should be similar - detect text in the document and process accordingly. Therefore, you shouldn't experience very obvious performance difference in regular scenarios. But if we are talking about large amount of documents and signatures within a single transaction, the complexity of the document (page number, character count, etc) and the number of signature fields could also affect the response time.

Duo