From DocuSign, this is developing with DocuSign
programming power forms.
I'm Larry Kluger, lead developer evangelist for DocuSign.
Embedded signing enables visitors
to your web application or web portal
to sign documents within the context of your web
application.
The signer does not need to leave your application
to find the signing request in their email.
Embedded signing provides a superior integrated experience
for your signers.
DocuSign has two developer solutions for embedded signing.
You can use either PowerForms, or the DocuSign eSignature API.
PowerForms are much easier to integrate,
but provide fewer options.
The eSignature API supports many more use cases
and includes all of the features available from the DocuSign web
app, but does require more programming.
To help API developers, DocuSign offers
SDKs for the languages shown here,
plus many code examples and other training.
This video focuses on using PowerForms.
Other videos in this series cover the DocuSign eSignature
API.
Adding a PowerForms embedded signing page
through your application is straightforward.
First, using the DocuSign web tool, create a template.
Then, again, using the DocuSign web tool,
create a PowerForm from the template and recorded it's URL.
Step three, your application redirects the user
to the PowerForm's URL.
And four, that's it.
I'll show you these steps later on during the demonstration.
Depending on your use case, PowerForm URLs
can also be sent to signers via email
and can be posted as links on web sites.
Additional options for your PowerForm.
Your application can include query parameters
with the PowerForms URL to set the signer's name and email,
envelope custom fields, metadata, and envelope field
values or tabs.
Using query parameters, your application
can set values for fields that are read only for the signer.
The signer can be redirected back to your application
after they complete the PowerForm.
The template and PowerForm can include some types
of signer authentication.
For example, KBA, knowledge based authentication,
access code, et cetera.
Pro tip, obscuring the PowerForm URL.
Obscuring the URL helps prevent people
from calling the URL on their own.
Examples.
A web form can return a redirect to the PowerForm.
Or a web form can include data fields.
Your server can then check and validate the field values.
And if correct, return a redirect
to the power form including the data field's values.
By using these techniques, the PowerForm's URL
is obscured from the signer.
But with a little work, it is always possible for a thief
to determine the PowerForm's URL and submit
an envelope on their own with their own settings.
The solution is to cryptographically sign the URL.
Here's a pro tip.
Detecting that the power form was started
outside of your application.
To authenticate that the PowerForm started
with your application, create a signed HMAC signer
app, a date, and et cetera, and add it as envelope metadata.
Since an HMAC signature is cryptographically
created with a secret key, only your app
can create or validate the signature.
PowerForms offer many benefits.
No DocuSign eSignature API program is needed,
no integration key is needed, no go-live process is needed,
and the branding feature can be used
to customize the look of the signing ceremony.
PowerForms do have limitations.
PowerForms are only created from a single template,
and the envelope's document set is fixed per PowerForm.
It's difficult to programmatically determine
the ID of the envelope created by the PowerForm,
and remember that PowerForms can be
started from outside your application from their URLs.
But depending on your use case, you
may need to guarantee that the PowerForm was
started via your application.
As I discussed previously, and HMAC
can be used to enable validation of the data in the envelope
that was set by your application.
The PowerForm's URL can also be obscured via a form,
but doing so is not a guarantee that your application submitted
the PowerForm.
By default, the signer is asked for their name and email
in a separate signer information form
when the PowerForm is started.
This form can be skipped for some use cases
by including the signer's name and email
fields in the template.
See the documentation link for more information.
Now, let's see a demo.
We'll start in the eSignature admin tool.
In the signing and sending section,
we've opened the envelope custom field screen.
This is the list of metadata fields
for your account's envelopes.
You can see that I've created three envelope custom
fields that we will use with the PowerForm.
The office and team fields are list fields
with specific value sets.
The order ID field is a text field.
Now, let's move to the DocuSign web tool.
We'll open the template list and then
we'll edit our demonstration template.
This template has one recipient sign a roll named signer.
We can also see the three envelope custom fields.
Moving to the tab editor's screen,
we can see that the template's document has a number of tabs.
Here's a summary.
There are three system tabs, full name, email, and sign
here.
There are also five data tabs.
All of the tabs can be set by the application.
The first name tab is read only.
It can not be updated by the signer.
The other tabs can be updated by the signer.
Back on the DocuSign web tool, here's the first name tab
and it's read only attribute is clicked.
We can also see the receipt check
box is clicked by default.
Next, let's create a PowerForm from the template.
Here's the resulting PowerForm from URL.
We'll save it as the first part of a URL on a new incognito
browser session.
In this series of slides, I'm showing
how to control the template settings from the URL.
Each item is a query parameter that
can be added to the PowerForm's URL.
Each query parameter name is introduced with an ampersand
and set with equal sign.
Spaces, ampersands, and equal signs
in both the parameter names and the values must be URL escaped.
For example, the escape sequence for a space is percent 20.
First, we combine the signer's role name
with user name and email to set those values
for the specific role.
We add the query parameters to the URL as shown.
We set the envelope custom field values
by prepending envelope field and an underscore
to the field's name.
Note the encoding of the query parameter name for the order ID
envelope custom field since it includes a space character.
And we add the query parameters for the envelope custom
fields to the URL as shown.
Lastly, we're also setting the data field values.
For the check box fields, we use the value X
to check the check box.
And we use a space character encoded as percent 20
to uncheck the check box tab that is checked
by default in the template.
Here's the complete URL.
Now, let's add all of these query parameters
to the PowerForm URL and open the page as the signer.
Remember that signers do not need a DocuSign login
or account.
We're using an incognito window to confirm
that no account is needed.
Here's the PowerForm.
All of the fields are filled in as we requested.
Note that we can change the values for the fields that
are not read only, but we can't change the first name fields
since it is a read only field.
The receipt check box is unchecked as set by the URL.
As the signer, I'll check it now.
Now, we've signed the form.
Back in the DocuSign web tool we open the PowerForm section
and click on the completed PowerForms link.
The envelope display screen shows us
that the envelope custom fields were set as requested.
That's it.
Here are the documentation URLs for PowerForms.
I've also included this information in the notes below.
Thanks for tuning in.
Be sure to subscribe to our YouTube channel
and click the notification bell icon
so you'll be notified for our next episode of developing
with DocuSign.