We want to open sender view of draft/created envelope in our application using REST API and allow sender/user to add signature fields/tags in documents. This sender view currently shows and allow all the options where sender can add new recipient or modify, can change the document and etc. But we want to restrict sender to only can add/edit signature fields/tags, we do not want to allow user to modify any other envelope information or even can send from there.
In short words: Want to open sender view of envelope only for edit signatory fields/tags using REST API.
Could anyone help how we can achieve this.
You can start the view on the tagging page by adding send=1 to the API call. Eg:
https://demo.docusign.net/restapi/v2/accounts/{account_id}/envelopes/{envelope_id}/views/sender?send=1
However the user can still go back to the recipients page if they want to by using the "Other Actions" menu item.
An alternative is for you to figure out what your users need to do on the tagging page and do it for them programmatically. That way you're both providing a better user experience for them and you don't have to worry about them changing the recipients or documents.
What are they doing on the tagging pages? It is not hard for you to programmatically place the tags by using anchor field locating. See the recipe.
Related
I am trying to include documents in my envelopes created via API that do not require signatures, but do require that only certain people see them.
I'm looking for a way to include these documents, keep them restricted to required parties. Any ideas? I'm still new to DocuSign API, so please let me know what other details I can share to help determine best course of action here.
Also, we are using C# for our APIs
Attempted to do this by having the people I need to see these documents as signers, but without the tags for where to sign and date. I am getting this error because we have the setting for "document visibility" set for this account, which is a requirement for this process.
*
"Error calling CreateEnvelope: {"errorCode":"ONESIGNALLSIGN_NOT_SATISFIED","message":"Freeform signing is not allowed for your account because it conflicts with other settings, please place signing tabs for each signer."}"*
Thanks!
For document visibility, each document needs at least on field (tab) placed on it. Whichever recipient the field belongs to will be able to see the document.
Plus, each signer recipient needs at least one tab or you're asking for free form signing, and that's not allowed with doc visibility.
The trick is that the field does not need to be a Sign here field. You could add a read-only (locked) text field. -- With no contents, so it would not be visible at all.
But at least one field per recipient is needed. If a doc has no fields then it is visible to all recipients.
Also, you can use confirmed cc recipients for people who won't sign but you want confirmation that they opened the envelope
See the docs
If you have more questions, ask a new stack overflow question
I am working on a DocuSign integration and want to allow the sender of the envelope to view the control panel to drag and drop signature tabs onto the document.
I already have a successful implementation that sends an embedded envelope to the signers. However, for this specific requirement, I do not know a) the X/Y coordinates of the signing tabs, or b) any anchor string for the signature tabs.
I have looked at the DocuSign api and I cannot see a way outside of java, which isn't really what im going for.
I am hoping to use this in an iframe, similar to how the embedded signing panel is done.
I believe the EnvelopeViews::CreateSenderView method is what you're looking for.
You can create a draft, then do the CreateSenderView call to request a url to a session of the DocuSign tagging screen. Since you're wanting to go straight to the tagger, you can leave the send=1 parameter as-is. If you wanted the URL to go to the Documents/Recipients screen instead of the tagger, you could change the url you recive from DocuSign to end with send=0 instead.
Do heed the Information Security warning on that API call: The Sender View URL will provide full access to the Web Console for whoever the authenticated user is. This is not a concern if you have one membership per user, but if you are using a shared membership everyone will have access to all envelopes on that membership.
I have been trying merge DocuSign in my application to make the user sign the documents I upload. Currently DocuSign allows us to add the signature tag at a static location, where we can provide the co-ordinates programmatically.
I would like to have a functionality where the signer can move the Signature tag anywhere over the page and insert the signature at the selected location.
Is there any good way to do this using DocuSign API's. Are there any DocuSign API's currently which do this?
Can anyone help me with this?
You want the signer to have the ability to dynamically position where the signature will go? Just send the document with no tabs at all and the signer will be asked to select the type of signing field (signature, initials, date, etc) and then choose its placement.
However, this is typically not a good UI. Instead, it is better for the sender to pick where the signer should sign. This can also be done dynamically using the "Sender View."
Not entirely sure about the part where the signer can move the tabs. But Anchor-Tabs sound like something that might help. I have asked a question on it a few minutes ago with sample code.
DocusignApi - Attachment with SignHere tab on the third page
The following link might also help.
DocusignAPI - Sign here tabs
I would like send an envelope with below two options.
Here we go,
User should sign in SignTab if it is first page of document.
User can sign anywhere if it is other that first page.
Is it possible to have this option using docusign API.
If Yes, Please let me know what are the parameters should I send?
Unfortunately you can only have it one way or the other currently- either you make the signing experience a Free Form signing experience (meaning the recipients can place tabs anywhere they want on any page of the envelope), OR you set 1 or more tabs in the envelope document(s) and the recipient will only be able to take action on those tabs and they will not be able to place tabs wherever they want.
The DocuSign Developer Center has a page devoted to Stick-eTabs under the Features section, they also talk about Free Form signing further down:
https://www.docusign.com/developer-center/explore/features/stick-etabs
When I make a meeting in Outlook, the recipient gets a approve/reject button in the top of the email. I'd like to do a similar thing with SharePoint: when a task is created, an email is sent to the person the task is assigned to, and the email asks the recipient to either accept or reject the task. I've seen demos of people doing this with a custom ASPx page, but I'd like to make it directly in the email. How should I go about doing that?
I'm used to making workflows in Visual Studio, so I'm happy with code examples for setting up an email and/or parsing the response
Cheers
Nik
The approve/reject buttons in Outlook shows up because the email is in the iCalendar format. I dont know if this is the best way, but you can send out your own iCalendar emails using C# code and set the response email to a mail server you control. From that mail server you can process the email and use the SharePoint WebService API to approve the item in SharePoint.
I like JMD's suggestion but I don't know how you'd interact with SharePoint from the mail server.
It might be a easier to send an HTML-formatted email with two links (...) for the Accept and Reject buttons. You could use CSS to format them so that they look like real buttons.
You could then create an ASPX page (or better an IHttpHandler implementation) to perform an action based on parameters passed to it via a URL. You'd want to pass in the site, web and list details and the list item ID along with a value to indicate whether the item is approved or rejected.
Then set the URLs of your "buttons" in the email to call your handler and pass in the appropriate parameter values.
The downside to this is that the "buttons" would be part of the message body and not part of the Outlook chrome but, on the other hand, they would be usable from any email client.