July Developer Ask Me Anything (AMA): Customizing the embedded signing & sending experience with Docusign APIs

👋 Hi everyone! 

I’m really looking forward to answering your questions and chatting with you all about embedded sending and signing this month! 

Here are a few resources on the topic to get the wheels turning:

• How to Use Docusign APIs to Embed Custom Document Signing in an App

• How to request a signature through your app

• How to send an envelope via your app

• Webinar - Enhance User Experience with Embedded Signing Focused View

Hi Paige,

I wanted to check if it's possible to enable embedded signing for signers within a Signing Group, particularly when we are adding the Signing Group through the API. Specifically, can we:

• Assign a clientUserId to the Signing Group recipient?

• Retrieve a recipient view URL for any signer in that group to initiate embedded signing?

Hello ​@paige.rossi 

Let’s take the real-life example: loan approval that requires a client to sign first, followed by an internal manager.

Question: How do I handle scenarios where multiple parties need to sign a document in a specific order “sequential routing”? And will it be coming under the “User advance recipient routing” of conditional recipient? 
 

👪 DocuSign Community Leaderboard Top 5 contributor
💹 Ranked #3 in the Reply Royalty category in DocuSign Community Wrapped 2024
🤝Let’s LinkedIn and roll: Pawan Gangwani - EY | LinkedIn

​@Maneesha  Unfortunately you aren’t able to use embedded signing with a signing group, because with embedded signing, your app is responsible for authenticating the signers and you need to know who the signer is before they can sign. If you want to send the envelope to a signing group, you’ll need to use remote signing.

​@Pawan Gangwani This how-to guide provides some example code for how to set up conditional recipients with Advanced Recipient Routing. If you want these recipients to be embedded, you’ll need to specify the clientUserId on the recipient, then call the EnvelopeViews: createRecipient endpoint for each signer to generate their signing URL. 

Why should I use embedded signing instead of simply embedding the envelope in an iframe?
Also, are any different configurations to set the iframe behaviour? We are having some scrollbar issues on prod, but not in testing and we have no clue why. 

​@MoisesW In general we don’t recommend using iframes because of potential security issues and because it can add unneeded complexity when troubleshooting issues in your signing workflows. This blog post gets into more details on the potential issues that can come up with iframes. 

If you do want to have the signing experience embedded on your page rather than redirecting your users to the signing link, you can do that with Docusign JS and focused view. Docusign JS also includes some StyleObject properties that you can use to control the look of the embedded display. It’s hard to say exactly what’s going on with your scrollbar issue but it may have to do with some of the weirdness that can be caused by iframes described in that blog post I shared. Using the styles in Docusign JS might be a place to start.

Hi @paige.rossi

Are there only case specific situations which we should embed in app VS url link VS on docusign site?  I am curious, for I run into security issues with a couple of documents (specifically, onboarding new employees - i.e. W -9, consultants' documentation & agreements, etc) that I need signatures for for my company. Another example is when I would like extra security protocol (i.e. work agreements) and can't seem to enable it on my additional current signing platform. So many options now-a-days, which are good, however as an owner we seek the simplist option - With the thought to also be able to automate in to current workflows within my company. BUT be able to keep and/ or implement security protocols/ features- ALL with EASE & SIMPLICITY! Thank you!

Working on it, thanks.

Question about the frameAncestors property, it is possible to use wild cards? I ask because we have some temporary environments for testing and would help to have the recipient URL created to [*.mydomain.com] instead of [first.mydomain.com, second.mydomain.com, dude.mydomain.com, ...]

Are there only case specific situations which we should embed in app VS url link VS on docusign site?  I am curious, for I run into security issues with a couple of documents (specifically, onboarding new employees - i.e. W -9, consultants' documentation & agreements, etc) that I need signatures for for my company. Another example is when I would like extra security protocol (i.e. work agreements) and can't seem to enable it on my additional current signing platform. So many options now-a-days, which are good, however as an owner we seek the simplist option - With the thought to also be able to automate in to current workflows within my company. BUT be able to keep and/ or implement security protocols/ features- ALL with EASE & SIMPLICITY! Thank you!

​@Jezika1369 The main consideration for when to use each option is the end-user experience that you want your users to have. Depending on the workflows you want to build the signatures into, you may choose a different option. For example, if you don’t expect users to come to your app or site at all, you might prefer remote signing. 

If you can share specific security protocols or error messages you’re seeing, I can look into any additional considerations that might be relevant. There are certain features that aren’t available with focused view including identity verification and some kinds of standards-based signatures so those would also  be considerations when deciding between traditional embedded signing and focused view.