CarbonCopy recipient issue - docusignapi

I believe there's an issue when sending out documents using REST API and 3rd party
accounts as senders where we try to get our account a cc back and it
doesn't appear in the management system while we get an email. This way the
envelope is not accessible when using our account and basically the only
option is to use the client account again to get the envelope status or
data. This does not reproduce when sending from that 3rd party account
using the DocuSign website. This way we get a correct CC that appears in
the 'completed' folder. It also works fine when sending form out DocuSign
account and setting the 3rd party account as a CC. This way this envelopes
successfully gets to their system. The difference that can be seen from the
API is that when a correct CC to our account is set, the userId is the same
as we can get from login_information request while in the case when we do
not get it into our system, the userId parameter is different but permanent across multiple envelopes sent while testing this way.
These test tell that it's not the case that CC person should be in the same
account with sender to get the envelope in his system. I've tested with 2
independent accounts and they still get CC and envelope access. I believe
that is a glitch or some kind of limitation and would appreciate any kind
of feedback on this.
(Also, is it allowed to send envelopes as other users under our integration if we
have their logins and passwords?)

I believe the system is behaving properly here. In the DocuSign platform, the account that sends a signature request is the one that has complete access to it. If you send a signature request from a given account and you include a CC recipient from a different account, then only the sending account will be able to see the CC in through the management system (i.e. the DocuSign Console).
The CC recipient from the other account will only receive the notification email and since they were not the sender they will not see it in their folders.

Related

DocuSign API Carbon Copy

Currently using the DocuSign API, I have a signer and an email to cc the completed documents to. Is it possible to send the completed documents to the docusign account of the (cc person)? For example, if I'm being cc'd the emails, I want my docusign account which is registered with the same email to be able to view my documents on the website. Can the API achieve this? I have already completed the part where the signer and the cc receives emails so for the most part everything is already working.
Yes, if the cc person has a DocuSign account, then they should be able to see the envelopes with their documents in it for envelopes they were cc'd on.
You can try this in the developer sandbox by adding a second user to your account. You can make the second user an admin or not.
I would second Larry's response, but point out that it's not enough for the email address to match exactly, but the full name must also match exactly what's in the DocuSign account. Otherwise - it will not be tied to the other account for this person.

Using docusign EnvelopeViews: createSender as preview

createSender creates a URL, which I would like to use to let the sender preview the document before it's send out. Hence the documents are created using templates and and the API.
The link which is created would lead me out of my UI. Does the user need to sign in? Future plan is to have many user's, which have no DocuSign account.
For embedded sending Your app will have to authenticate the user. If you are doing a Service Integration then your Api account will be used as the sender.
Once the sending url is generated using the createSenderView api, there is no authentication required to access the URL.
You also have an option to build a User Application using the docusign Api where your App can support sending from multiple accounts.
The createSenderView requires that the person is a DocuSign user (with their own account and password).
Only DocuSign users can send. We charge for sending, not for signing or receiving.
What exactly do you want to preview? (And why?)
the documents themselves? Use the EnvelopeDocuments resource. You can also preview the thumbnails of the documents.
the documents with the "fields" ("tabs") that indicate where people will sign? I'm not sure that is do-able.
or the recipients and their routing order? Use EnvelopeRecipients: list method.
Added
Another solution is to use a dummy certified delivery "recipient". Add this recipient as the first recipient. This will block the envelope from proceeding on the recipient routing.
Then get the envelope's documents to show as a preview.
Then, if ok, alter the envelope's recipients to remove the certified delivery recipient. The envelope will then continue on with the first "real" recipient.

docusign access code authentication mail

If I set the recipients to get Access Code through email, then do I need to program separately to send the email with access code or Docusign API will automatically send the access code email to all recipients?
Also do I need to enable any setting from my DocuSign account to turn on this feature? I have a developer Docusign Account.
When using the Access Code authentication feature, it's up to the sender how to actually get the code over to the signer. For example, if you have their phone number you can call them and give it to them. Or you can instant message them or send an SMS, or some other means. In general though I would shy away from sending them the code through email as that pretty much defeats the purpose of multi-factor authentication (i.e. if someone has compromised their email they will get both the signature request email AND the access code email).
Similarly, the SMS Authentication feature is used the same way but in this case the code is explicitly sent to their mobile phone number. With Access Code it's up to you how to provide to the recipient.

Docusign : How to send confirmation email with link to embedded signer

I am using the DocuSign API in an embedded manner. I create an envelope and add signers, the first signer always being set as embedded. This allows me to retrieve a URL that is then embedded in an iframe.
However, I also wish, to trigger an email (as soon as the envelope has been created, NOT upon completion) that gets sent to the primary recipient/signer as if they were a nonembedded signer.
I tried adding the signer twice, with the same role, to the recipients, but that didn't work. No email was sent.
Is there a way to accomplish this?
I believe there is a setting to enable this but that it needs to be enabled by someone on DocuSign's side, like your account manager. If you do not have an account manager yet please respond to the auto-generated emails that were sent out to you once you created your account, you should have 3 of them.
The account settings available are only for Completion emails. However, the REST API also supports an embeddedRecipientStartURL parameter on the signer object that triggers a normal DocuSign email. The value of this parameter is the URL that should be included in the email. This means you can link back to your own application and request the recipient view as normal.
Check here for more detail: Signer embeddedRecipientStartURL. Note: if you set this to a value of "SIGN_AT_DOCUSIGN" then DocuSign will provide its own URL and take care of signing. The trade-off is that you won't be able to initiate any bespoke authentication you are doing in your own application.

Provisioning limited DocuSign REST API Access

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

Resources