I am trying to write a DocuSign integration where a customer uploads a PDF file and sends it to a list of signees. The customer should not have to place the right amount of anchors in the document. Instead, a new page (or several pages if necessary) for signatures should be added to the document automatically, with one signature box per signee. I want to avoid modifying the PDF myself. Is there any way DocuSign can do this for me?
The easiest and best way to do this would be to utilize anchor strings, which you've mentioned above that you would rather not do. Normally under these circumstances I'd recommend using a template, however you've indicated that you want the customer to be able to upload the PDF, correct?
The issue there comes down to document dimensions. If you were using a template, the coordinates for a tab would be stored in the template and be applied automatically. If your customer is supplying a PDF, you don't have a guarantee on how small or large the page dimensions will be. IE: An image taken with a Retina display vs. a 6MP camera would be like a Post-It Note vs. a calendar. The remaining option would be to find a standard set of coordinates that would work. For example, when a customer upload a new PDF always have a signature or initial tab applied at x/y: 0,0 so it will always appear at the top left.
Alternatively, what we would normally recommend is that the customer add in a unique identifier like /signer1signature/, then apply the tab via anchor string where it will be applied at every instance, even if it's a single instance hidden on the signature line.
Related
I would like to know if it is possible to show/hide parts of DocuSign document template depending on the data which is passed in as a request.
I already have document template created and uploaded to DocuSign. I then use templateId to create envelope for that document and I also send some data (as json) to prepopulate certain fields inside the envelope.
The thing I am asking now is:
If the template has, let's say, 3 paragraphs, is it possible to hide one of them completely, based on the passed in json data?
Creating and uploading multiple templates is not an option due to large number of conditionally displayed sections.
I have been reading DocuSign API documentation, but couldn't find an answer to this.
To do that you will have to use Responsive Signing.
This feature change the format of the document you sign from PDF to HTML.
With HTML being the format, there are a lot more things you can do.
For example, you can use what we call "Smart Sections" which is exactly what you want. Sections that can be shown off/on based on logic you set.
Find out more about the responsive signing API here - https://developers.docusign.com/esign-rest-api/guides/responsive-signing/api-overview
I am using embeded signing and I have noticed that the checkbox's are in different locations at different stages.
I can either make it look correct while doing embeded signing... the check mark is centered in the box, or I can make it so that the check marks (X's) are properly centered in the summary pdf.
However I do not know how to consistently get the check marks to align in both the embeded interface, or the pdf summary...
anyone solve this?
This is not the answer you're hoping for but -- unfortunately, there are not separate settings to specify the location of a form field during signing versus on the completed document (PDF). You only get one opportunity to specify a field's location (during the Create Envelope process), and DocuSign then automatically determines location of the field in the completed document (PDF) -- presumably using the same coordinates that you specified during the "Create Envelope" process, although not always exact (as you've discovered with the checkbox element).
So, the best advice I can offer is to always verify placement of fields BOTH in the signing view AND in the completed view -- and then use trial and error to specify field location in a way that produces best overall results across both views.
I am sending documents for signature from salesforce using DocuSign. I am having an issue with aligning the tag - \s1\, \t1\, \d1\ on the document.
My understanding is Docusign will replace tags automatically for specific signers to sign. But they are off by few pixels and come over the line marked in the document.
could anyone tell me how i could configure sure that the user don't enter details over the line on the document but above the line.
Thanks in advance for the response.
Getting proper tag placement with anchor text usually takes some trial and error -- i.e., testing DocuSign tag placement based upon various positions of the anchor text strings (\s1\,\t1\, \d1\, etc.) that you put in your document(s).
One tip: If you're creating your documents (i.e., adding the anchor text strings) with Word or something similar, putting each anchor text string inside a textbox (with no textbox borders) is a good way to give you more finite control over tag placement -- because you can move the textbox wherever you want to, regardless of where underlying text exists in the document. For example, here's a screenshot from Word where I've added an **\s1** tag inside a textbox, and placed it precisely where I want it over the signature line:
If I sent this document through DocuSign and thought the Signature tag was placed lower than I wanted it to be, I'd just edit the document to move the textbox up a few pixels (without affecting the signature line placement itself), and then re-test.
Background: We use the DocuSign SOAP API method CreateEnvelopeFromTemplatesAndForms for a very clear reason (mainly, we don't want to keep track of page numbers and X/Y coordinates) and we do not want to stop using this api method (unless there is another method that doesn't force us to keep track of page numbers and X/Y coordinates). I mention this before someone happily suggests I use another method.
Problem: We've recently been asked to send large envelopes through the DocuSign api (could exceed 100 mb). I know that DocuSign doesn't place a limit on envelope size, but rather on size of payload per api call when the envelope is created. I think what we need to do is the following, but I am having trouble:
Step 1: load up to 50 mb in the templates
Step 2: call CreateEnvelopeFromTemplatesAndForms but set the ActivateEnvelope parameter to False
Step 3: load up to another 50 mb in the a new set of templates
Step 4: call CreateEnvelopeFromTemplatesAndForms again but this time set the ActivateEnvelope parameter to True.
Is what I'm trying to do possible? I keep getting an error that says the "TransactionID has already been used." If what I'm trying to do (in general) is possible, any code samples would be much appreciated.
I believe Anchor Tags is a viable and easy to use feature that should solve your issue here. With anchor tags you can still use the CreateEnvelopeFromTemplateAndForms() API call but you won't have to specify page numbers or (x,y) coordinates for your DocuSign Stick-eTabs. Instead, those tabs will get "anchored" to your documents based on content that it finds in the document itself.
For instance, let's say you have a document that needs to be signed and in the document where the signature should go you have the text "Sign Here". You can have the system place a signature tab close to this "Sign Here" text. You could have it place it X amount of pixels to the right, or Y inches or cms to the right, etc.
You can add these tabs at the account level, which means they will get applied whenever their corresponding text is found in ANY envelope you create in your account, OR you could add them in your API request so that they are only used on that particular envelope.
For more info please see the following links:
Previous Stack Overflow Question
Explanation on Dev Center - look at Tab Positioning section
I am using Visual Studio 2010, SharePoint 2010 with custom document content types and forms. And plan to also use jquery to build the document add/edit/view forms.
I am developing a solution where I want to have a document library where each document uploaded also has a number of external data elements added as metadata.
The tricky part I'm trying to figure out is I want the user to be able to specify and add a multiple number of those same external data elements.
I'm trying to figure out how I represent the data internally in SharePoint. My initial thought is to programmaticly add hidden external fields as the users adds those external selections. But then I also think of simply storing those external elements as non-external text fields but have my own code which performs the external data lookup and validation.
I'm not adverse to significant custom coding, as I'm probably going to need to do a lot anyway since even the user interface is going to be a jquery tabbed form to enable all the external data the user will be able to associate with each SP document.
I've made an attempt to hopefully further explain what I'm trying to do and included that image. Essentially I'm wanting to add 1+ external data relationships to each document, as desired by the user.
It uses just example data. I'll actually have 4-7 different complex relationships much like the example. And the user is permitted to drilldown and select 1, 2 or all 3 of the dropdowns.
Think of it as similar to how here on Experts-Exchange we can add multiple zones to a question.
An example illustration is here: http://flic.kr/p/aFUSJn
Could you simply add a multi-line text column and have the user input the metadata with comma's, then use your code to seperate the data and do what you want with it?
You said you were not adverse to significant custom coding :)
One solution is to use SharePoint content types. The trick is that not all items in a list need to have the same content type.
Therefore, you can do the following:
As the user is selecting the fields he wants to use you generate or select a content type that matchs those fields.
You then add your document to the document list using the content template
You then have all your information strongly typed in SharePoint lists.
We have previously built a system where we generate content types based on xsd files, this worked very well.