Sender and Signer fields indistinguishable

Anyone have an idea how using the API for a sign request could cause the Sender

and the Signer fields not to be distinguishable?

• The doc signing image I showed in the previous post shows a deletable field.
  
  – That field is a Sender field, so I’m wondering why the Signer can change it.


• I noticed that this also happens with the [[n|0]] tag.
  
  – It is treated the same as the [[n|1]] tag.
  
  – The Signer can change it and in doing so, the [[n|1]] tag changes in real time as well!

It’s like it thinks the Sender and Signer are the same. (In my tests they are 2 different email addresses.)

Is using the API causing it to merge the Sender document initialization steps with the signing?

Because there are Sender fields, does there have to be some two-step process with the API as well?

Any insight into the problem or what I’m doing wrong from anyone would be appreciated.

Thanks.

Update:

I did some experiments and it seems that tag id 0 is not being reserved for the Sender–What happens is that the first recipient is also considered id 0, hence 0 fields are writable by the first recipient/signer if they are not the Sender!

What I’m trying to accomplish is to use API calls to modify sender fields without having to email the document to the sender to do so. I would think this would be a reasonable thing to do with the API.

I even tried to set the sender as a signer and set ‘has_viewed_document’ to true, in an attempt to skip sending an email to the sender, but it didn’t take (was false in the sign request response.)

How do I accomplish this?

Thanks.

I should also mention that when I tested using the Sender as a signer

(document first emailed to Sender to fill a Sender field):

When the document got to the next Signer ( id 1 ):

Where the Sender filled the [[n|0]] tag field, an editable field was shown

right on top of the n|0 text that the Sender entered

This is totally broken behavior that shouldn’t even be possible IMHO.

Please advise as to workaround or, if any, obscure thing I could be doing wrong that could cause this.

(I have been waiting for a response for quite some time now, so I don’t know if box has made any related fixes in the last week or two.)

Thanks

Hi @Moo

Let me share my thoughts after doing similar tests on my side. I should alert you however that I am using a template created within the box app. It does seem that you’re creating a template using tags from a document as explained here.

Now I’m not sure if there are some caveats between these 2 techniques or any issues between the above and the usage of a template_id in the API sign request.

To be clear, I’m using a formal sign template, created manually using the box.app, I’m also create the sign request using the template_id in the /2.0/sign_requests POST end point of the API.

In the most common use case the sender does not need to interact with the document, and it is skipped in the process, however your use case does require it. This changes things a bit.

Here are my findings:

A Signer is anyone who needs to do something in the document, not just sign it, so since your sender needs to input something to the doc, then it becomes part of the whole process.

In order to have the sender populate the field before the actual signer, order becomes important, so you might need to specify in which order the interactions go.

I believe this would solve your use case.

Please do let me know if this makes sense for your use case, or if I’m missing something.

Cheers

Hi @rbarbosa. Thanks. As I explained previously, my desired use case is to not have anything sent to the Sender at all.

I just want to set Sender fields via the API, and send off the document to the Signature Signer.

My last message described a test which also shows the

Tag Ids 0 and 1 somehow treated as the same

problem when the Sender was actually emailed to set a field (as well as when they are not,)

to demonstrate there are still issues even in this particular scenario

to show that the issue is not just simply a confusion about what is the “first Signer”

( Because if it were simply that, the 2nd Signer would not be given an editable field

for [[n|0]] because as to my understanding tag id 0 is reserved for the Sender. )

Yes, I am using a document with template tags.

I do not get why there would be differences if done another way.

Please research and advise about differences/gotchas you can find, and workarounds.

(Please do a test with a template created via a document with tag id fields of 0 and 1

and via the API set the [[n|0]] field to something, and then have the document go

out for signing to the Signer–who I am assuming should correspond to tag id 1 fields.

And if you can make it so the Signer cannot edit any id 0-specified fields,

please let me know how you did it.)

As I mentioned, I cannot see any justification for treating tag ids 0 and 1 as the same

(Problem being: Designated fields editable by both Sender and last Signer,

whether Sender is an emailed “Signer” or not.)

I should note that in my experiments, I also attempted using the “Specify Signing Order” feature in the template editor to no avail in my attempts at a workaround.

I understand that the signer index does not perfectly track the tag id–

Maybe this has something to do with the problem?

Thanks

Hi @Moo I am a developer on the sign team. Is it possible for you to provide the request payload and pdf with template tags used for us to replicate the issue and identify the problem?

Thanks @tgolbasi – I messaged you with what you requested.

This is what the Signer saw and could edit: