UNKNOWN_ENVELOPE_RECIPIENT when creating recipient view for embedded signing

Question

Out of many envelopes created, we have one where we cannot create the recipient view URL for embedded signing. In the sample test below, one of the two envelope IDs fail with

    DocuSign.eSign.Client.ApiException : Error calling CreateRecipientView: {
       "errorCode": "UNKNOWN_ENVELOPE_RECIPIENT",
       "message": "The recipient you have identified is not a valid recipient of the specified 
     envelope."
      }

while the other envevlope ID passes. Note we create the envelope with the ClientUserId and the Email set to the same value. We use the technique of setting the UserName to the values specified with GetRecipientsList (and always have), but yet it still fails, so this appears different from similar issues already answered.

    [Theory]
    [InlineData("redacted")]
    [InlineData("redacted")]
    public async Task ShouldCreateRecipientView(string envelopeId)
    {

        var accountId = await new DocuSignCredentials().GetDocuSignAccountIdAsync();

        var envelopesApi = new EnvelopesApi();
        var recipientList = await envelopesApi.ListRecipientsAsync(accountId, envelopeId);
        Assert.Single(recipientList.Signers);
        var signer = recipientList.Signers.First();

        var viewOptions = new RecipientViewRequest()
        {
            ReturnUrl = "http://localhost/return",
            ClientUserId = signer.Email,
            AuthenticationMethod = "password", 
            UserName = signer.Name,
            Email = signer.Email,
        };

        var viewUrl = await envelopesApi.CreateRecipientViewAsync(accountId, envelopeId, viewOptions);

    }

Edit: if we set the viewOptions like the following, it still fails the same way. The control envelope ID continues to pass.

        var viewOptions = new RecipientViewRequest()
        {
            ReturnUrl = "http://localhost/return",
            AuthenticationMethod = "password", 


            ClientUserId = signer.ClientUserId,
            Email = signer.Email,
            UserId = signer.UserId,
            RecipientId = signer.RecipientId
        };

Answer 1

can you add the RecipientId to the RecipientViewRequest object? and make sure it matches what you used when creating the envelope? that should help identify which recipient you are looking for by the system.

Answer 2

This turns out to be Docusign bug with signature adoption.

1. Create an envelope for some recipient
2. The recipient signs a field, adopting a new signature and Full Name, and does a "finish later"
3. Create a second envelope for the same recipient using the exact same addressing parameters as the first envelope
4. The recipient signs the second envelope, and this is the critical part, adopts a second signature (while they can still see the first signature) with a different full name, and again does a "finish later"
5. The recipient attempts to open the first envelope; the embedded signing Create Recipient View will now fail with "unknown recipient" as the recipient info in the envelope doesn't reflect the latest Full Name attached to the recipient user id.

If your embedded signing code can figure out the latest Full Name that was adopted, and uses that for the UserName parameter when creating the recipient view, then it will work. But obtaining that latest Full Name is difficult due to authorization constraints.

The work around we are using is to force a new Docusign user id for every envelope by using a random string for the ClientUserId when creating the envelope. Not entirely satisfactory as the user signing experience is no longer optimal -- they have to accept the "electronic signature and records" terms on every envelope, and they won't be able to maintain a list of signatures. And it doesn't help for all the broken envelopes and the envelopes we have already created.

Answer 3

As kayjeta has noted, there's an edge case involving multiple in-flight envelopes and multiple signatures adopted for the same captive signer. The end result is an envelope where the GetEnvelopeRecipients call returns a name for the signer that doesn't match what's present in the envelope, resulting in a failing request for a recipient token.

To resolve this, the application can either:

1) Make the Recipient Token Request using the original name that was defined when the envelope was created

2) Take the results of the GetEnvelopeRecipients call and plug it in to an UpdateEnvelopeRecipients call to 'resync' the envelope and bring everything back in to alignment.

A Product Issue has been filed against this behavior. It's tracked internally as EC-1965.

Answer 4

If the captive recipient has not completed signing, the original recipient information will continue to work. If they have completed signing and you want to return them to the envelope at some subsequent point in time, then you will need to GET the now-updated name and use that for the recipient view API, OR you can get the userId and use that in place of name & email for all subsequent uses of "Recipient View". I recommend the latter approach as changes to the name by the signer does not affect the assigned "userId" value.