Send a document to an non-approver/signer

Hi Peter,

Thanks for your post!

If the form preparer is the sender him/herself, you can consider #1 assigning label fields to the actual signer #2 during the package creation, presenting the Designer page (either open in a new tab, or embedding into an iFrame) to the preparer where they can enter the default values for those label fields #3 preparer can send the transaction from the Designer page, or you can disable the button and have them send from your application.

For more information, you can refer to my blog: https://www.onespan.com/blog/onespan-sign-developer-designer-customization-and-integration-part-1

Another solution is still to treat the preparer as a signer, so that you can assign text fields along with a small-sized signature (almost invisible) to the preparer and have them sign before the actual signer.

Duo

Thanks Duo! These are great patterns to consider!

If we go down the designer route, and disable the button to send (since we use SF and not OSS to send the actual email), what button does the sender/form preparer need enabled on the designer once they have finished populating the document. Is there a save button?

Also, would you mind expounding on what you mean by "#1 assigning label fields to the actual signer".  I am not sure I am fully following what you mean. 

Thank you very much.

Hi Peter,

For the Designer path, you don't need a save button to have the changes take effect, those are done in real-time.

Why I wanted to highlight the label field (vs text field) is because the label field is designed to display values and is uneditable during the signing. Once the signer completed signing, those values will be stamped on the document.

Duo

Got it! Make sense.  

Do you think this Designer profile is sufficient for our needs? I only want the preparer to add values to the text fields.  Do I need the 'editDocument' button?

1. “saveLayout” & “applyLayout” button  - OFF

2. “documentVisibility” button - OFF

3. “addSigner” button - OFF

4. “editRecipient” button - OFF

5. “addDocument” button - OFF

6. “editDocument” button - ON

7. “deleteDocument” button - OFF

8. “send” button for package creation or “done” button in template creation - OFF

9. The following additional fields can be hidden – HIDE ALL

• signingDate
• signerName
• signerTitle
• signerCompany
• textfield
• checkbox
• list
• radio
• textarea
• label
• datepicker

Hi Peter,

I believe that option means to rename the document, hence it shouldn't be necessary for your use case.

Duo

Hey Duo,

Am I doing something wrong on this? See the screenshot. I see "label" on all the inputs.  Is it possible to make the experience just like a real document signing - where I can enter a value in the field itself and see the value in the field?  It looks like I need to select the field and enter a value on the right side panel.  Is that the only way this works?

Thank you!

Peter

Hi Peter,

Unfortunately, I think "to select the field and enter a value on the right side panel" is the only way for a sender to set default field values.

Duo

Thanks Duo.  That is unfortunate.  I am thinking we'll switch away from designer to the pattern of sending the document to the sender first and placing a tiny signing block.  I really want the user to easily and clearly populate the form directly.  

I'd like to offer a feature request (my apologies if this isn't the place)... It's directly relevant to this thread.

We'd love to see a profile of the Designer that would be intended for the sender to populate the input fields with values before sending to the first signer.  The experience would be just like when a signer is entering values during the signing ceremony - typing directly into the fields rendered on the document rather than into the sidebar.  This would also be a great way for a sender to preview any document before sending.  For our implementation pattern this enhancement would be very valuable - since we are handling the merge field creation / placement via our template-based architecture using the SDK.  

Hi Peter,

Sure! I would more than glad to raise this enhancement request on your behalf! I will reply back the reference number in a short time.

Duo

Hi Peter,

I've created the ER for your, the reference number is OSSSAAS-I-1733. If you are currently working with other OSS team, you can also share the number to them and have them vote/comment on the request.

Duo