0
votes

We have a use case where the same user needs to sign as two different recipients on the same Envelope. This seems to be working, more-or-less. See below for the GET Recipients response for one of our test envelopes. As you can see, two different recipients have the same userId value.

{
    "signers": [        
        {
            "signatureInfo": {
                "signatureName": "test",
                "signatureInitials": "T",
                "fontStyle": "freehand575"
            },
            "tabs": {
                "signHereTabs": [
                    {
                        "stampType": "signature",
                        "name": "SignHere",
                        "tabLabel": "Sign Here",
                        "scaleValue": 1,
                        "optional": "false",
                        "documentId": "1",
                        "recipientId": "2",
                        "pageNumber": "1",
                        "xPosition": "191",
                        "yPosition": "123",
                        "anchorString": "@SW1R",
                        "anchorXOffset": "0",
                        "anchorYOffset": "0",
                        "anchorUnits": "pixels",
                        "tabId": "19f2a250-7ffc-4452-b7e2-e0bf1fddd660",
                        "status": "signed"
                    }
                ]
            },
            "creationReason": "sender",
            "isBulkRecipient": "false",
            "identityVerification": {},
            "name": "test",
            "email": "[email protected]",
            "recipientId": "2",
            "recipientIdGuid": "215d99bb-5c50-4bdd-b298-21639d0aad4c",
            "requireIdLookup": "false",
            "userId": "386ae756-5c1c-480e-abd5-94d960781f5c",
            "clientUserId": "49b09797-cea5-4d87-b653-49f13f733dd3",
            "routingOrder": "1",
            "status": "completed",
            "signedDateTime": "2019-08-02T21:21:53.9570000Z",
            "deliveredDateTime": "2019-08-02T21:16:54.9800000Z",
            "totalTabCount": "4"
        },
        {
            "signatureInfo": {
                "signatureName": "test",
                "signatureInitials": "T",
                "fontStyle": "freehand575"
            },
            "tabs": {
                "signHereTabs": [
                    {
                        "stampType": "signature",
                        "name": "SignHere",
                        "tabLabel": "Sign Here",
                        "scaleValue": 1,
                        "optional": "false",
                        "documentId": "1",
                        "recipientId": "3",
                        "pageNumber": "1",
                        "xPosition": "189",
                        "yPosition": "167",
                        "anchorString": "@SPAAR",
                        "anchorXOffset": "0",
                        "anchorYOffset": "0",
                        "anchorUnits": "pixels",
                        "tabId": "e2def7a9-bfdb-404d-8901-e387d9e4f856"
                    }
                ]
            },
            "creationReason": "sender",
            "isBulkRecipient": "false",
            "identityVerification": {},
            "name": "test",
            "email": "[email protected]",
            "recipientId": "3",
            "recipientIdGuid": "0b6541f4-45b7-4b6e-a4cb-740d2f9f07a7",
            "requireIdLookup": "false",
            "userId": "386ae756-5c1c-480e-abd5-94d960781f5c",
            "clientUserId": "49b09797-cea5-4d87-b653-49f13f733dd3",
            "routingOrder": "1",
            "status": "delivered",
            "deliveredDateTime": "2019-08-02T20:36:14.5170000Z",
            "totalTabCount": "4"
        }
    ],
    "agents": [],
    "editors": [],
    "intermediaries": [],
    "carbonCopies": [],
    "certifiedDeliveries": [],
    "inPersonSigners": [],
    "seals": [],
    "witnesses": [],
    "recipientCount": "3",
    "currentRoutingOrder": "1"
}

Our concern is when we make the POST EnvelopeViews: createRecipient call. We have found that this seems to return a recipient view for whichever recipient does not yet have a completed status. Is this dependable/deterministic? We have tried specifying the recipientId in this request, but it does not affect which recipient view we receive. For example, the following request returns the view for Recipient 3 (delivered) instead of Recipient 2 (completed) as requested.

{
  "authenticationMethod": "email",
  "email": "[email protected]",
  "returnUrl": "http://www.google.com",
  "userName": "test",
  "clientUserId": "49b09797-cea5-4d87-b653-49f13f733dd3",
  "recipientId": "2"
}

Update - More details around the business requirements:
We create an envelope with 2 captive recipients, Presenter and Agent. At the time of envelope creation, we do not know who will sign as the agent, so the initial recipient is a placeholder user. Later in the business flow, we determine who will act as the agent and we call the DocuSign API to update and "swap" the Agent recipient's email, clientUserId, and username to be that of the actual user who will be signing. This is a process which we have been successfully using for years.

We now have a case where the Presenter and Agent could be the same person, but the Presenter must complete their signing before the Agent (same person or someone else) can sign. When they are the same person, following the "swapping" method described above, we still have 2 recipients but the Agent recipient has the same userId as the Presenter recipient.

My main concern is regarding whether the POST EnvelopeViews: createRecipient method is deterministic because it seems to ignore the recipientId parameter. I want to be sure we can reliably do the following:

  1. Allow the Presenter user to complete signing.
  2. "Swap" the same user in to sign as the Agent.
  3. Successfully get a recipient view for the user as the Agent recipient.
1

1 Answers

0
votes

what exactly are you trying to do? when a recipient is complete, you still want to create a recipient view for that recipient? even while the same recipient has to still complete this envelope further down the routing order? This is most likely not a supported scenario. I would suggest that if the same exact person needs to act on an envelope more than once, and they completed their first interaction, then the next request would/should take them to the next interaction. It doesn't make sense to do anything else IMHO.