Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from Failed DocuSign Integration

profsmallpine.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Lessons from Failed DocuSign Integration

#61

Post by kevindong »

bdauvergne wrote: post #59

All those online signatures "click to sign" services are useless anyway, they have absolutely no legal value anywhere (their EIDAS/ETSI whatever are just buzzwords), even in France from where docusign is coming. https://www.cryptomathic.com/news-events/blog/us-court-rejec...

That article is pretty clear that the docusigned documents were invalid due to that specific court's rules.

To quote from the ruling [0] directly:

> Although DocuSign affixations and other software-generated electronic signatures may have a place in certain commercial and other transactions, they do not have a place as substitutes for wet signatures on a bankruptcy petition, schedules, statements, and other documents filed with the court, and they do not comply with this court’s local rule.

[0] (see page 7) : http://www.caeb.uscourts.gov/documents/Judges/Opinions/Local...

Re: Lessons from Failed DocuSign Integration

#62

Post by DaiPlusPlus »

kevindong wrote: post #61
bdauvergne wrote: post #59

All those online signatures "click to sign" services are useless anyway, they have absolutely no legal value anywhere (their EIDAS/ETSI whatever are just buzzwords), even in France from where docusign is coming. https://www.cryptomathic.com/news-events/blog/us-court-rejec...

That article is pretty clear that the docusigned documents were invalid due to that specific court's rules. To quote from the ruling [0] directly: > Although DocuSign affixations and other software-generated electronic signatures may have a place in certain commercial and other transactions, they do not have a place as substitutes for wet signatures on a bankruptcy petition, schedules, statements, and other documents…

A real solution is a proper PKI - a great way forward would be if the US federal government issued citizens with X.509 digital certificates when they get their passport renewed: they’ve done the task of verifying identity, they just need to co-sign a cert and give people $5 smart cards with their $100 passports.

With state-sponsored PKI we can eliminate so many headaches and rockblocks in the digital economy and paperless government.

Re: Lessons from Failed DocuSign Integration

#63

Post by matchagaucho »

inoda wrote: post #14

I was on this project and can speak a bit more on the technical details here. A couple of high level goals: 1. We wanted to use their embedded flows, to keep the experience within our application as much as possible. 2. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 “API user” to make requests, handling data scoping ourselves wi…

Were the contracts user generated, or your own standard template?

If the latter, then embedding your own signature tags into a standard template seems like the simplest use of DS API.

Wondering why their tech support didn't share this solution. Or maybe it's no longer supported(?)

(Full disclosure: I helped design the DS REST API and their Salesforce AppExchange app many years ago)

Re: Lessons from Failed DocuSign Integration

#64

Post by SnowingXIV »

propter_hoc wrote: post #48

FWIW, I've developed a lot of this sort of tool. For some reason, Adobe E-sign services (formerly known as EchoSign) rarely comes up, but it's actually quite good and cost-effective to develop with. Docusign is indeed pretty terrible as an API, but it does have the benefit that users have heard of it so it has a certain institutional credibility - which is usually important if you're developing the sort of app that n…

Saw this article and was familiar with the headaches of esignatures. HelloSign is very pretty but I've been using Adobe Sign for years now. When we had to switch from Business to Enterprise (I don't remember what limitation required the upgrade but it was business critical - edit: ah yes, I remember being able have a clickable link that generated a new one for each person). There was some friction because the support and people working on it seem to be handled by a different group of Adobe. There were two different logins, kinda weird. Couldn't sign up through the site and had to do a manual contract. After dealing with the technical team the migration worked and all is well, very nerve wracking time thinking you lost all your contracts. We had backups but still.

Anyways, one of the biggest issues with other services was the max amount of templates imposed by HelloSign and the rest. It feels very arbitrary yet Adobe can handle this at scale very cost effectively.

The UI needs work and some quality of life changes need to happen. I feel like it's been somewhat abandoned after the acquisition. If I need to edit a template with one tweak I have to completely redo the entire contract/document which is time consuming especially on multi-page contracts with tons of fields of different types.

We're married to it now and it does work but I would love to see enhancements or have Adobe at least get a few new designers and UI/UX people onboard.

Re: Lessons from Failed DocuSign Integration

#65

Post by inoda »

matchagaucho wrote: post #63
inoda wrote: post #14

I was on this project and can speak a bit more on the technical details here. A couple of high level goals: 1. We wanted to use their embedded flows, to keep the experience within our application as much as possible. 2. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 “API user” to make requests, handling data scoping ourselves wi…

Were the contracts user generated, or your own standard template? If the latter, then embedding your own signature tags into a standard template seems like the simplest use of DS API. Wondering why their tech support didn't share this solution. Or maybe it's no longer supported(?) (Full disclosure: I helped design the DS REST API and their Salesforce AppExchange app many years ago)

Users (our app users) would have created their own templates and used them for sending envelopes.

Re: Lessons from Failed DocuSign Integration

#66

Post by larrykluger »

I am DocuSign’s Lead Developer Evangelist. Thanks to Joseph (OP) for writing this up and to everyone who has contributed to this thread including both the positive and negative comments about integrating with DocuSign.

The problem OP ran into is really one of documentation and not a bug or security issue.

I agree that our docs for the embedded sender view should clearly state that the method’s URL gives full access to the sender’s account, and we’ll fix that ASAP. As others have commented, the assumption of this API method is that each sender has their own account. I also agree that the OP’s use case, which requires that the sender view’s capabilities be strictly limited to the current envelope, is valid. It is under consideration for our roadmap.

A workaround: I recommend that API applications complete the sending process programmatically including document tagging, etc. This also provides the best user experience for the sender.

We actively monitor and reply to the “docusignapi” tag on StackOverflow (I’m “Larry K”), if you want to reach out to us there.

Re: Lessons from Failed DocuSign Integration

#67

Post by f0rgot »

rblatz wrote: post #26
inoda wrote: post #18

Earlier quoted context omitted.

You have definitely struck my curiosity - which version of this integration I outlined did you guys implement? 1. Embedded views + user creation w/o requiring email confirmation 2. Embedded views with 1 API User I don't want to assume anything here, but I think you either didn't build exactly what we were trying to, you are on the legacy version of their API, or you have that embedded view refresh bug I outlined live…

I just checked we are using the v2 rest api. We create a user, we do not send them an email, we then add the documents and setup the envelope, then direct them to the user's embed signing room. I wish I could find the old postman POC since that would make it a lot easier for me to explain exactly our sequence of api calls.

We use v2 API as well and like rblatz said, we haven't ran into any problems.

Our backend signs in to DocuSign as the main account. When a particular event requires it, the backend sends a POST to DocuSign and creates an envelope. In this POST request, we tell DocuSign that the user is going to be an embedded user. Once the envelope is created, we can ask for the "view url". In this request, we not only tell DocuSign to get us the vie URL for a specific signer (in case there are multiple signers), but we also tell DocuSign where we want the user to be redirected to after they are done signing. When this request returns, we will have a URL that we can redirect our end user to.

Also, in terms of their documentation, I think it is fantastic in it thoroughness.

All in all, I've had the opposite experience of OP.

Re: Lessons from Failed DocuSign Integration

#68

Post by justinclift »

inoda wrote: post #60
inoda wrote: post #14

I was on this project and can speak a bit more on the technical details here. A couple of high level goals: 1. We wanted to use their embedded flows, to keep the experience within our application as much as possible. 2. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 “API user” to make requests, handling data scoping ourselves wi…

I'd like to add a little more to this - our main frustration isn't necessarily because of these technical difficulties. Communicating implementation details and 3rd party integrations can be challenging, especially if one side of the convo is not super technical. That is totally understandable, and probably inevitable. The main reason this felt so...sucky for lack of a better term, is that we had multiple discussions…

Sounds like the - unfortunately very common - thing where sales people make promises which aren't delivered on.

Seems to be the sales people doing this get bonuses regardless, even though the customers get shafted, and their own tech staff generally get shafted too. :(

Re: Lessons from Failed DocuSign Integration

#69

Post by justinclift »

larrykluger wrote: post #66

I am DocuSign’s Lead Developer Evangelist. Thanks to Joseph (OP) for writing this up and to everyone who has contributed to this thread including both the positive and negative comments about integrating with DocuSign. The problem OP ran into is really one of documentation and not a bug or security issue. I agree that our docs for the embedded sender view should clearly state that the method’s URL gives full access t…

> The problem OP ran into is really one of documentation and not a bug or security issue.

Thanks for admitting fault. How about:

a) Refunding them, as they requested.

b) Creating a follow up post and submitting here to HN when the docs are actually fixed. After all, the article itself describes many instances of them being told things would be fixed. Your doing so here on HN will be regarded the same way. eg by actions rather than words

Re: Lessons from Failed DocuSign Integration

#70

Post by justinclift »

diminoten wrote: post #2

> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time... Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH? This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a s…

> Also, an maybe this is just a cynical view, but when you start your cautionary tale with a literal, "It all started when I was 11", it's kind of hard to relate.

I can relate to that, so guess that one's on you. ;)

Post reply on HN