Noting simple steps to reproduce this. I’ve filed a support ticket as well back on Friday but no response yet.
#1. Create a PDF document to use as the Box Sign Template, it will contain only the following HTML:
<div style="width:200px; display:inline-block;">Name: </div>
<div style="width:150px; display:inline-block; text-decoration: underline; border-bottom:1px solid black; text-decoration-color: black; color: white; font-size:14px;">t;t|0|id:personname ]]
</div>
</div>
<br><br>
<div style="min-width:250px; display:inline-block;">
Signature <span style="color: white; text-decoration-color: black; text-decoration: underline; font-size: 16px;">t;s|0 ]]</span>
</div>
Upload that template file into Box.
#2. Create a sign request using that PDF template, this can be done either via an API call to https://developer.box.com/reference/post-sign-requests/ or directly in the User Interface on Box.com using “Request Signature”
#3. Send the request to the signer and have signer complete the request.
#4. Make a call to Box Sign API to get the completed Sign Request via https://developer.box.com/reference/get-sign-requests-id/
/sign_requests/{sign_request_id}
#5 See that document_tag_id is empty on the two fields, even though “id” was explicitly set in the template as seen in the HTML above. document_tag_id should be depositbwrname but instead is NULL
This worked perfectly fine prior to sometime on June 12th or June 13th when document_tag_id started coming back as null for newly created sign requests that use Box Sign Template tags.
Just noting, creating the template manually via the UI and setting an external id results in the subsequent sign request having the document_tag_id, it seems to only be broken for sign requests that were created from template files which were hand-created and uploaded. All this worked fine though prior to June 13th or so.
I have the same issue. Any news about the fix?