Gotcha's account

With regards to Keeping track of the signers, may be I'm looking at it differently and do not see the whole picture from your prespective ( the RESTAPI). So let me give you a summary of the problem I see. 1. We have a lot of legal forms from various Centrals , Province, Federal. 2. All of those forms are designed to have either one Applicant to Multiple Applicants ( Up to 4). What this means is that they will have predefined section for one applicant or multiple sections each reserved for each of the applicant on the loan. ( Example Primary Applicant, Co-Applicant, Guarantor 1, Guarantor 2). For each of the above mentioned applicant, we have a corresponding Signature Field at the end of the form. 3. On a typical loan, when we print, we assemble all the FORMS required (the form set) which consists of a mix of a Per Applicant Form ( example a Member's Financial Statement) to a Combined Form where all Applicants on the Loan will appear under their corresponding sections. As an example, For a loan with a Primary Applicant and Co-Applicant, Imagine our Form Set consist of : 1. Member Financial Statement for Applicant A with 1 Signature Field (Merged data on this PDF will contain Member's A Information) 2. Member Financial Statement for Applicant B with 1 Signature Field (Merged data on this PDF will contain Member's B Information) 3. Combined Loan Application . This form includes all the details of the Loan Application, so will include the Applicants and Guarantors. In this case we will have 2 out of the 4 pre defined sections on this PDF prefilled. Normally, our software will merge all data related to the PDF Templates we have ( Those templates are PDF with TextFields, Checkboxes...etc defined in ADOBE - The text Fields are mostly fields which we use for extracting and merging data - we will be adding NEW Signature Text Fields according to your format SignerId#.Cature#). All forms will be merged and combined into 1 PDF of multiple pages. Some of the fields, like the Signature Fields will therefore remain unmapped until we CreateAndSendPackage to the REST API. In other words, we combine all the PDF into 1 PDF and this is when we are ready to send it over for Signature Package Creation and eventually the Signing Ceremonu. So my challenge is that because we will have to define the Signature Fields according to your nomenclature, we will therefore create those new Signature TextFields in all the PDF where the Signature is required.: 1. All Signature Fields will have a prefix "SignerId"#.Capture# - So if there are 2 Signatures on the forms for 2 different applicants, we will keep the prefix "SignerId" and just change the # for each of the applicants. 2. When we create the JSON payload, our system will know exactly how many signer roles to create in the payload. However, each PDF may have different number of (predefined) Signature Capture TextFields. In my case for the Combined Loan Application, the PDF will have SIgnerId1.Capture1, SignerId2.Capture2,SignerId3.Capture3, SignerId4.Capture4; where only SignerId1.Capture1 and SignerId2.Capture2 will be defined in the JSON Payload ( as they are the only 2 applicants on the loan with NO GUARANTORS). Based on your recommendation, our logic will need to prepare a payload with 4 signer roles because the PDF has 4 Signature Fields, right? So this is where it implies I will need to keep track for each PDF i'm about to print how many SIgnature Fields there are so that I fill it with dummy data in the payload. If I can compare it with the competition ADOBE ECHOSIGN, They handle this in a similar fashion for Document Extraction. However, if the signers are not sent in the payload, the Signature Field is Ignored at runtime during the signing Ceremony. As such, I can have 4 pre defined signature fields according to the SIgnature Nomenclature but yet only send 1 Signer Role. Hope this helps defining my constraint and requirement . Let me know if this makes sense ... I'm hoping i'm wrong about this validation on the SIgners in JSON vs SIgners predefined in the PDF approach - or if there is another approach to this?

As for other options, one I had thought of before but didn’t suggest because of the messy JSON you could encounter (and redoing your forms), is to not use the eSL naming conventions on your fields (use custom names) and only extract the necessary fields for the number of signers. Again, this creates a more complex JSON payload as you must now define all fields in your JSON.

Hi Michael, I'm interested in this bolded piece where you suggest "I can only extract the necessary fields for the number of signers "? LIke I mentioned, I came from the ADOBE ECHOSIGN for extacting Document Signatures using special tags in the PDF - so I thought the ESL naming conventions are the only way to go about defining the SIgnature Fields... From the sound of your suggestion, I do not need the ESL Text Fields but rather I can define it in the JSON, did I understand correctly? Can you extrapolate on this? I'm not afraid of the JSON strings as Im using the Serializer/Deserializer classes based on a sample JSON which worked just my tests. In other words, as long as I know how to structure the JSON ( the schema) , I can create a class out of the sample and always ensure I send the same format with the proper information... Let me know ... I just want to make sure I try all available methods before i report it back. Thanks

Ok I was able to overcome the problem where I thought I had to save the number of Signature Controls on EACH of the PDF as some kind of meta data. I've used the principle that I can send a DRAFT with a max no of signers = 6 ( This is the maximum of Signature Controls which we can have in some PDF ). So by populating the Roles with actual signers , then filling up with DUMMY data, then Deleting the DUMMY roles in a subsequent CALL.

Hi Michael You mentioned last year about the possibility of having Optional Signature Fields so that the application does not report an error when the JSON payload does not match the Capture Fields in the PDF being uploaded to create a package. In the PDF package which our Application generates can have a variable number of Signature Fields ( each of which are based on the type of application being printed ). Our templated PDF are all edited to contain the Document Extract Tags eg [SignerId#.Capture#] at pre determined spots on the legal forms. Some of the forms may have 1 to 6 signature fields. So we are creating those tags for each of those signature fields with the Document Extract Tags. Since not all Signatures may be applicable ( example if only 1 applicant , 1 out of the 6 fields on a typical form will be requested to be signed SIgnerId1.Capture1 ... The other fields SIgnerId2 to 6 although are on the PDF will not be assigned to anyone as there is only one applicable signer. Until now, I'm using the DUMMY ROLES filled with DUMMY DATA , as you suggested to work around ... So my JSON payload on the initial upload with the pdf will contain 6 roles where only the 1st one is the actual role required to be signed. Then Issue a delete signers (2 to 6) . Can you please let me know if this feature is available? Can you point me to the relevant info / url I need to achieve this?

Unfortunately, optional signatures is still not on the roadmap (unplanned backlog). Each quarter, our Product Managers review the backlog for potential enhancement requests to be put on the roadmap. I will let you know once optional signatures are on the roadmap. Haris Haidary, Technical Evangelist eSignLiveâ„¢ by VASCO – When e-signatures matter to your business Tel: 514-337-5255 ext 1806 E: [email protected]

The work around, until this feature is implemented, is to create dummy roles, signature definition in the JSON on Creating the package with DRAFT and then deleting them in a separate call.