My company recently signed up for partnership with DocuSign to build your
signing routine into our software.
The client looking to use our software currently uses DocuSign to sign
documents and has an integration with eOriginal as the eVault for the
documents.
Based on the documentation I'm reading, when the document is sent to
eOriginal, it is removed from DocuSign.
Is that correct? My client vaguely agreed that it wasn't on DocuSign but
I'd like to verify this.
We have our own document storage system as well and while we would like
eOriginal to have the authoritative copy of the document, we'd like a copy
of the document to be stored in our solution.
Our initial thought was that after the document was signed, we would
download a copy through your API and store it on our system.
We now wonder if that document would be there.
How soon after a document is signed would be it be pushed to eOriginal?
If there isn't enough guaranteed time to pull the document down, we'd need
to possibly pull it from eOriginal instead.
If we are pulling it from eOriginal, is there any information on how that
would be identified in eOriginal.
I'm not asking for their API. I get that we most likely need to get in
contact with them but is it identified by the same envelopeID?
Please let us know any insight you can provide on this.
We appreciate your assistance
The Setup
The configuration you're using all depends on your account settings. Please contact your DocuSign Account Manager to get a better explanation of the options and pricing here.
The most commonly used combination that I see with DocuSign/eOriginal is:
DocuSign Transfers Authoritative Copy to eOriginal
eOriginal stores the Authoritative Copy
DocuSign stores a copy
As far as timing goes, the event happens when the envelope has been fully completed. It could be anywhere from less than a second up to 15 minutes, depending on how DocuSign and eOrigional's queue's look. It's normally closer to the "instant" side. But I would plan for latency between the two systems.
How eOriginal Stores Envelopes from DocuSign:
eOriginal uses EmailSubject of your Envelope for the Containter ID.
There is an additional eOriginal Custom Field Xref1 which contains your DocuSign EnvelopeId
Related
Question??? My company is using docusign for esignatures and we have run into a situation were we need to have the signed copies of the documents without the copy view watermark on them. To remove them we have turned to a site called eoriginal which will clean up the docs and remove the cope view watermark, however we are continuing to have numerous issues with this service. So I am attempting to find an alternative solution, any feedback or suggestions are much appreciated.
Not knowing what your issues are, I'm not sure I can help, but have you looked at our dev center article about how to export authoritative copy using the DocuSign eSignature SOAP API? It covers this topic in details and explains that you can do this given the following prerequisits:
You must use the SOAP API
Your account must have access to the
Authoritative Copy feature. Contact DocuSign Customer Support and ask
that your API user be granted permission to export Authoritative
Copies.
If you want to select which envelopes will record an
Authoritative Copy, add "authoritativeCopy": "true" to the envelope
definition in your API call.
If you want all envelopes to use
Authoritative Copy, ask DocuSign Customer Support to set the "Auto
Authoritative Copy:" to Enabled on your account.
Finally, it's important to note this is a one-time action, and once it is done - you can never do it again (for a given envelope).
I'm developing a connector between our platform and Docusign.
We need to create a Draft envelope in Docusign with a specific account and then transfer the ownership of the Draft to another account.
Looking at the documentation I've not found any clue of how we can do that, I just found how to create transfer rules but they don't fit our use case.
Envelope Transfer Rules can either happen at the point of sending, or the point of completion. While it's still a draft, an envelope cannot be transferred.
Additionally, Envelope Transfer is not currently available through the REST API, so all-or-nothing transfer rules are effectively the only option.
Envelope Custody Transfer is only currently available for accounts that are part of the same Organization and on the same server. You can see which server your account is located on by going to Settings > Apps & Keys and checking the value for your account's baseUrl. For example, if both accounts have a baseUrl of www.docusign.net, they can transfer between each other. If one is on www.docusign.net, and the other is on na2.docusign.net, you cannot transfer the envelope.
Please see the following for additional details: https://support.docusign.com/en/guides/org-admin-guide-envelope-transfer
I am an admin account user and to get insights from data I need to pull the details of all the envelopes from all accounts. The similar thing is what a report provides in Docusign dashboard but I need the list of recipients as well. Can anyone please help me. Thanks.
Listing envelopes sent by your users: Envelopes::listStatusChanges
I think that call may cover envelopes sent by anyone in your account (if the accessToken represents a user with admin privileges). But I'm not sure.
If it doesn't then you can loop through the account's users.
Tracking who has received an envelope through their DocuSign account is done with the Folders::listItems API call. You may need to list both the Inbox and Deleted folders. You also need to check that the person signed the specific envelope vs receiving it for some other reason (cc, certified copy, etc).
Finally, an alternative if you have higher volumes is to purchase the DocuSign Report Feed product (see note below). It will send you DB table dumps about your account activity on a regular basis so you can do your own reporting on DocuSign activity. It is the best way to have full access to report data. Ask your DocuSign contact for more info.
Note: I'm not sure of the exact name for the reporting product.
This can be done if you install DocuSign for Salesforce managed package and use Connect feature in DocuSign. Configure your webhooks to create DocuSign Status and DocuSign Recipient Status records for each send. Any DocuSign objects or custom object can be used in the Connect configuration, after selecting objects, select which events you want the results to be pushed back to Salesforce.
Use a parent object to store envelope details and child object for the recipient data. Use Envelope Id to relate the child records to the parent. Eventually, you will be able to build various reports on Salesforce.
More info here: https://support.docusign.com/guides/dfs-admin-guide-ds-connect-for-salesforce
I am trying to set up Docusign in Salesforce so that when a document (Quote) goes out, it goes to the Approving Manager first, and then his signature triggers the document to go the the customer.
Once the Quote is completely signed by all parties, I need for several people to receive a copy of the signed document, not just the person who sent it. I also need the completely executed document to be saved in Salesforce.
This is part of the work flow for the company-wide Quote process in Salesforce.
It would be helpful to provide details of what you've already attempted to get this working. This seems like a very basic case of using the Routing Order value of Recipient. Your Approving Manager recipient would be Routing Order 1, other signers all Routing Order 2, and the people who need copies can be Routing Order 3.
A 3rd party website is offering our service to their members. When they sign up, members have to agree to our contract. Currently this is handled manually, with envelopes being sent through email. We want to streamline this process allowing members to enter their information into the web site, and then immediately be presented with a contract to review and sign.
The 3rd party web site will collect the member information, then use the REST API to create a draft envelope based on a Template and information the the member enters on the website. The application will then display the contract in the web page so that the user can review and sign it. The document workflow will ensure that signed copies are routed to appropriate parties within our company via email for completion.
We want the 3rd party web site to have access to an account to which we can share templates. We want the 3rd party application to have very limited capabilities trhough the API:
Submit requests using a User ID and Integrator Key that we provide. These credentials need be different from other User Ids and Integrator Keys under our account
Create a draft envelope based on the templates we provide
Post a Recipient View allowing the application to display the document for review and siganture (in an IFrame)
Receive the signing status via the return URL provided in the Recipient View post
Possibly request status for an envelope
The external application should not have access to other templates, documents, or unnecessry API calls.
We want to be able to cancel the application's access at any time.
Question: Permissions and API Limitations
Is the above scenario feasible with respect to establishing limited access to the DocuSign REST API? How would we set this up?
Do account user permissions limit API use, if the API is enabled for the user? I found these settings in the user permissions section of the documentation. I can make guesses as to how to set them, but I need guidance on the actual implications of some settings.
Submit DocuSign API Requests: true
Manage Account: false
Send Envelope: true
Manage Templates: Use
DocuSign Desktop Client: false
Transfer Envelopes to User: false
Allow sender to set email language for recipients: false
I assume "Account-Wide Rights" should be false, but under that option in the documentation, it lists RequestStatus as one of calls covered. Will an application embedding the signing process still have sufficient permissions to complete the tasks listed above if "Account-Wide Rights" is false?
Are there other settings or issues I need to consider?
Firstly, thanks for using DocuSign. The answer to your question is in a few different parts. To clarify, I am answering assuming:
1.) You are a current customer (or about to be one) of DocuSign.
2.) You have a plan that is set up to allow integration (IE you aren't trying to do all of this with a personal plan, or something like that).
There are a couple of terms I will use... Sender and Recipient. In this scenario, the THird Party Website is "the sender" and they are Sending the documents through YOUR DocuSign account, using the API. The people who are signing up for your service are going to be Envelope Recipients.
Just like with the post office, someone has to send, and someone gets the envelope.
So far so good.
So what will happen is that the third party website will write some code that knows how to talk to the DocuSign API, and you will need to know:
-DocuSIgn Account ID (this is your DocuSign account)
-The Integrator Key (this is the key that you will need to certify before going live, which identifies all those API calls as coming from them)
-Credentials to access your account (this can be either the actual creds, or a token, etc).
Now, there are two ways to do it. You can either have the third party website make the and send all of the envelopes as if they all came from a single "user" in DocuSign (likely) or if you know that a particular user should send out things, you can do that too.
I am going to assume that all of the sign up packets will be sent as if they came from something like Signup#company.com.
So you will make sure you have a user in your DocuSIgn account with that Email address and name, and make sure that user has the ability to send via the API (there's a setting in DocuSign admin), and all envelopes will be sent as if that "person" sent them.
You will need the settings for that user (the one that will "send" all the envelopes), set as you showed above. You would need the Account Wide access if you wanted to send "on behalf of" a different user. But you aren't doing that, so you should be cool.
The last thing is that you will need to make sure you have an envelope based plan (as opposed to a seat based plan) because otherwise, that one mega-user will look suspicious (sending hundreds of envelopes in an automated fashion).
I hope this answers the question?
-Dan