I'm Steve Parrish.
I am an engineer-- a lead engineer on the click team.
Today we'll cover a little bit of creating, configuring
Clickwraps, as well as embedding them
in a website as the main focus.
And yeah,
I don't know if you guys saw a little bit about what
click is so far, but a Clickwrap, essentially is a--
for DocuSign is the simplest form of agreement.
Ideally it's just a text and a click to agree.
The idea is that we take away a lot of the compliance issues
with the normal terms of service and privacy
policies you see today and we simplify the developer
experience, as well.
So first I'm going to kind jump into just creating a Clickwrap
and if you want to follow along, you can.
If you have a sandbox account, Clickwraps
are enabled on all sandbox accounts to demo
right now, so yeah.
Let's make sure I can actually exit out of this.
So if you login to your sandbox accounts right now,
along with envelopes you now will see Clickwraps.
I'm going to sort of stick to the UI
side of this instead of the API side for creating Clickwraps.
Largely for Clickwraps the management portion--
the main use case is through the UI.
The main developer case is a little downstream,
actually embedding them in the website.
So I already have a couple here--
two different use cases.
One is inline.
One is modal.
So I'm going to go ahead and just edit this one.
So you get a nice preview of what your agreement will look
like, finally, on your website.
This one's inline, so it works well
in cases where you have, like a web form of several fields,
like a purchase order and then an agreement,
like a EULA at the end.
So then there's also a few other options
we allow them to customize, like whether you want a check box
and whether you need them to read
or not, and where you want the button to be placed.
Along with that, we also give you a history on our audit log
versions, so one of the main infrastructure portions
of Click is that we want to support the ability to create
new versions of a document.
Terms of service and privacy policies change over time
and the acceptance around them changes over time,
so we want the ability to either require a re-acceptance
if something breaking in the document changes,
if there's a new clause in the document
that you want users to re-accept that they've already accepted,
like, say, V1 down here, they should re-accept V2
or they should be forced to accept V2
even though V3 is active.
So largely, versioning is a core piece of Click
in that it enforces any changes you have in your documents
over time as well as configuration.
So, like, if you were to change any of these settings in Click
right now, it would be a new version.
You can decide whether or not you
want that to re-accept a new version,
whether it forces users that have already
accepted to sign again.
But it puts you in the driver's seat to control that.
One of the things that's very different about Click
in comparison to normal e-sign is we actually
remember who has signed.
We're able to look up when you load
a Clickwrap if a specific ID has previously signed
and we determine if we need to present an agreement or not.
So that's how we're able to do these things, like versioning
and enforcing versions across--
enforcing agreement across versions.
So with that, I'll jump back to the slides a little bit.
So kind of one of the things I was pinging on,
like one of the main options you have
is whether your agreement is displayed modal or inline.
From dealing with embedded signing for a long time,
we found that there was several complications with dealing
with iFrames and web pages and we wanted to sort of take away
some of that complication.
We provide a client-side JavaScript SDK for you
to embed in the website and say watch Clickwrap
you want to load, and you decide whether you want that display
modal over your web page so that you prevent
the user from interacting with a page underneath,
or if you want to be inline at the bottom of the form,
like I was mentioning before.
The benefits of modal is you get a bit of the interaction
and we manage for you the iFrame sizing and responsive portions
of the UI.
For inline it's more similar to our normal embedded
signing use cases, where you're managing,
really, the size and width of the iFrame.
It's up to you.
But we handle like, the redirects and callbacks
that you usually would have to create a web server to handle.
We take that for you now.
And then, like I was saying, versions
is the other key portion of configuring a Clickwrap.
Every change you make is a new version and an audit trail.
Requiring re-acceptance is how you enforce if a signer needs
to resign on a later version.
The active version controls which
one is actually presented.
Jumping into embedding a Clickwrap
and then we'll get into demos of how you get a better Clickwrap.
This is really the JavaScript snippet
that you'd have to include in your web page.
Really, only the idea is that we take away
the need to do the envelope post call or the recipient view
call.
Instead you can embed this Clickwrap snippet
in your web page to render the agreement wherever you want to.
In this example, like, the last parameter down here
is where you'd want it to render in which element in the page
you'd want it to render.
Yeah, so it's kind of pointing out
the key properties-- the only ones you actually
need to provide are account, Clickwrap, and the user ID
that you want to sign, along with where you want us to put
the Clickwrap in your web page.
And then, jumping back, actually, before I move on--
the client user ID should be a unique ID
that you tie to your user.
This specific ID should be a unique ID
that you tie to your user in your system.
This is how we determine if a user has previously
signed a version before and if we need to represent
them a new version.
And then the other thing we provide in the SDK are
ways to handle the callbacks.
Usually through embedded signing these
are handled through redirect URLs
and where we land after they agree or decline
or whatever those actions may be.
In Click, those are handled through a set
of callback functions that are more client-side based.
So you have the ability in one place
to integrate with Click without having
to own a server that you're redirecting
to that sends a post message back up to your client page.
We get to handle that for you.
So these are actually all optional.
You don't need to specify any of these callbacks
if you don't want to.
But if you want to know, example, being on
must agree when a user needs to agree
or you want to present something different in your UI
you can do that.
If when they complete an agreement,
you want to present something different.
You want to show that they've logged in successfully
or the UI changes in some other way, you can do that.
And any error that we may present, like,
through configuration or whatnot will come
through the on-air callback.
So yeah, we'll jump into, if you want to,
there is a handy page that will help you.
Like if you were to configure a Clickwrap in your demo account
now, you can easily paste that Clickwrap ID
and try it in a web page at this link, if you want.
And I'll show them again at the end if you're curious
and want to take note.
So going back to the managed portion
so after you create your first Clickwrap,
you can click Get Code and it shows you like a very base
snippet you might need to paste into a web page.
Obviously, a unique user ID should
be replaced with whatever's coming from your system
to identify your user, but otherwise everything else
is exactly as you need it.
So I'm going to go ahead and take my count.
Let's go.
Let's make a fresh version of this, actually.
If you go to that URL mentioned before for the Clickwrap test
page, it allows you to put in the environment which
would be a demo for your sandbox account, the account
ID and Clickwrap ID.
The sample web page is already running the snippet for you
so you don't have to, just to make it a little easy
to see what your Clickwrap looks like in a web page at all.
So this is just a sort of a sample website
of what a login might look like if you
put a Clickwrap around it.
Actually, I've already agreed with that user.
That's my bad.
The problem there is that I've already agreed with that user
and so it skips right past the login,
whereas usually it would present an agreement.
If I were to, I guess, upload a new version of the agreement
to the managed portion of the UI,
it would actually be required that a user I tried before.
But yeah, again, from here this is just an inland view
so it's just displayed right in the page
rather than over the entire page.
It's up to you to how you want to control the UI for it.
You can set a specific with if you want to.
It's really [INAUDIBLE] Clickwrap.
You can set whatever you want to around that element
and we'll just control the iFrame within for you,
and I'll just agree.
And then this particular sample website
is using the on agreed callback that we
saw earlier to just redirect to the finished login page.
You can see all of the source for this is actually on GitHub
and you can pull and figure out how it's implemented.
I'll post the link at the very end for that, too.
And then, showing off really quickly,
the modal view, as well.
That's my bad.
Again, I keep trying with that same user.
And as you can see for this one, we actually
handle all of the rendering.
We put it over the web page so you don't have to.
Typically, this is a fairly tricky thing.
Every time we've done any embedded e-sign integration,
usually the customer needs to build their own model,
manage an iFrame height as the browser changes size,
they need to change the height and width.
And we sort of take that away and say
we're going to do that for you now,
which was kind of a big thing.
I feel like we've prescribed a lot of solutions
over the years, as far as how to handle the iFrame,
how to handle embedded signing and this
has been a very nice way to simplify it on our side, too.
So some of the niceties of this is
we will handle it responsibly for you
so you can not have to worry about mobile.
We'll do that for you in modal mode.
Inline, not as much.
We kind of let you be in control.
I'll go ahead and agree here, too.
Yeah.
I'm logged in.
And then, I guess, one last demo or two I will show
are the actual snippets you can try and do.
And the idea, hopefully, is you can
see all of these callbacks I have in here are actually
optional.
But actually, let's do an alert.
Typically, I would maybe mutate my UI somehow,
or like the other Clickwrap test page did, but in this case
I will run it as is and I'll just have a console log
and an all agree.
So here's my log right here, which is the must agree,
and then I'll come through and do this all from the client.
The idea for Click is that it is incredibly simple in comparison
to some of the e-sign uses.
So, yeah, and that has agreed pops, too.
All right.
And then we will also present, depending on the setting,
I think on this particular Clickwrap I have download
enabled, and you can download at the end if you want to, too.
If you wanted to, you could also entirely hide the element
when it completes by just writing your own JavaScript
here to hide it.
And I'll just modify the user ID so I'd actually
get a new agreement.
If I kept it the same it would just show me nothing
because it's already completed.
That's my bet for running it on the page.
In this case, I don't want it to show anything when I finish,
and it goes away.
So you kind of get a little bit of easy control
over the like process of the agreement from the click
is stick it.
So, with that--
I kind of want to link back to some of these resources.
If you can follow through with any of the other APIs guides
or walkthroughs, the Click API guide on developers
on [INAUDIBLE] is pretty amazing,
as well as the page that I showed you and walked you
through--
the Clickwrap test page by Larry Kluger--
also amazing, as well as the source to it
is very cool to see as far as how you might
do your own Clickwrap, too.
We can dig through a little more of that if you want,
but otherwise, it's very quick.
Thank you.
I to open up to questions.
Yeah?
Are Clickwraps associated with [INAUDIBLE]??
They have-- there is technically an envelope
underneath the covers for it to track.
There's the usual things you get with an envelope, like a CFC.
Yeah, I guess I could show that if it's useful, too.
Yeah?
What about the types of text you hit
that agree button [INAUDIBLE] check box.
Are there any other types of text [INAUDIBLE]??
Not at the moment.
For Click, the idea is--
at least not at the moment.
The idea is that the documents are pure text.
And everyone has the same document
and you're all agreeing to the same thing at the moment.
Does it support multiple users for a single agreement?
Yes.
Or I guess, do you mean like, multiple users signing it?
Yeah, agreeing to a single document
or is it just per signer.
Per signer.
So yeah, every Clickwrap is a separate agreement
for one user.
Yeah.
Yes?
Does this integrate with Spring CM at all to actually like,
tag the document?
To tag them?
No.
You can, you know, report, like which
ones, if you change a company's law at some point,
you can report on which document.
Which documents need to update in a Clickwrap?
Yeah.
Or, just like, if there is someone
going for an acquisition and wanting to see which--
just the reporting of everything.
[INAUDIBLE] particular set of data.
Well you could--
I don't know what I did, but you could certainly
integrate Spring CM on the outside to update
a Clickwrap like to create a new version upon like, a policy
change.
That's something--
Can I file the document within Spring CM so then it tags it?
You could.
We don't have anything like that now,
but that's definitely where we're open to doing that,
for sure.
That makes sense.
At least at least I think I follow.
Yeah.
In general, these slides for the breakout [INAUDIBLE]..
Yep, the deck, as well as a recording, too,
of the walkthroughs will both be available.
And I think you had a question?
You showed the off-screen setting.
Is that--?
Oh yeah.
[INAUDIBLE]
Just scroll.
Yeah, yeah.
I didn't show it off today, but yeah, you
would have to scroll to the bottom of a document
and then agree.
There is also a check box setting
to enforce that you check an agreement first
before you can click agree.
There's a few other things coming in,
like a different display of the document,
rather than just the one scrolling view.
There is a link view of like, several documents
you may link to and pop over as separate modals.
And those have like a, must view setting.
So you have to actually open them and look at them
and then you can also set a must read on those, as well.
It makes it a little easier to manage the multiple documents.
It's short and sweet because I think
Click is honestly, supposed to be
fairly simple as is the idea.
But yeah.