Apex Toolkit: Customizing Change Requests in Salesforce

also by Neel Kumar

Lauren: In this episode of Docusign Developer Deep Dive, Fred Wade, Director of Engineering, showcases The Apex Toolkit, which is a handy tool to quickly create solutions that administer Docusign eSignature for Salesforce, send envelopes, and retrieve envelope status.

Fred walked us through an easy example of sending an envelope with the Apex Toolkit using your Salesforce data—all in your Salesforce developer console!

Want to see something a little more complex? Let me hand it over to Neel...

Neel: Here at Docusign, we take uptime and security for our production environment very seriously. To this end, we use a Change Request process to push certain changes into the production environment. When someone initiates a Change Request (CR), they have to fill out pertinent information that is saved into a document, and that document goes through the signing process, making sure certain experts look at the requested change and agree to it.

We can see many of our customers doing the same within the Salesforce environment. They may already be doing parts of it and don’t want to radically change the UI or the flow. At the end of the process, these customers may want to create an envelope and send it off for signature. Thanks to the Apex Toolkit, the customers can customize without needing to learn our public-facing REST API or the JSON serialization and deserialization, status codes etc. They can simply use Apex classes that Docusign has built and made available as part of the Docusign eSignature for Salesforce Essentials managed package.

Here is an outline of how to set things up when all approvals go to a single person. Once you have installed the Essentials package, you can generate the envelope by following these steps:

1. Create the envelope.

   Id mySourceId; // The ID of the initiating Salesforce object.  This may be a custom object that you have created that tracks changes to your system // Create an empty envelope. dfsle.Envelope myEnvelope = dfsle.EnvelopeService.getEmptyEnvelope(new dfsle.Entity(mySourceId));

2. Add the approver to the envelope. Here we are explicitly adding exactly one approver, and the template supports only one role.

   // we will use a Salesforce contact record as the approver here Contact myContact = [SELECT Id, Name, Email FROM Contact LIMIT 1]; // use the Recipient.fromSource method to create the Recipient dfsle.Recipient myRecipient = dfsle.Recipient.fromSource(   myContact.Name, // Approver's name             myContact.Email, // Approver's email             null, // Skipping phone number              'Approver 1', // Role Name. Specify the exact role name from template (referenced below)              new dfsle.Entity(myContact.Id)); // source object for the Recipient // add Recipient to the Envelope myEnvelope = myEnvelope.withRecipients(new List<dfsle.Recipient> { myRecipient });

3. Create a new document and attach it to the envelope.

   // myTemplateId contains the Docusign Id of the Docusign Template of the approval form.  This template will contain pointers to fields in the custom object referenced in #1 that will be populated before being presented for approval.

   dfsle.UUID myTemplateId = dfsle.UUID.parse('01234567-xxxx-xxxx-xxxx-456789abcdef'); // create a new document for the Envelope

   dfsle.Document myDocument = dfsle.Document.fromTemplate(     myTemplateId, // templateId in dfsle.UUID format     'myTemplate'); // name of the template // add document to the Envelope myEnvelope = myEnvelope.withDocuments(new List<dfsle.Document> { myDocument });

4. Send the envelope.

   myEnvelope = dfsle.EnvelopeService.sendEnvelope(     myEnvelope, //  The envelope to send     true); // Send the envelope now

The action in step 4 will trigger the sending of the envelope to be signed by the approver.

This is how you can send an envelope programmatically without disrupting any existing flows.  And you don’t need to learn about status codes and other nuances of the Docusign eSignature API. This example can be modified to add additional capabilities, such as a second (or third) approver, signing groups (so that no one person is overloaded with the task of approving changes), or dynamically picking different templates based on the kind of action that needs approval. If the company’s organizational structure is already in Salesforce, you could potentially make the supervisor of the person invoking the approval process to be the first person to sign off.

The possibilities are endless!

Ready to get started? Create a free Developer Sandbox account on the Docusign Developer Center and head to the The Apex Toolkit material.

Watch Docusign Developer Deep Dive: The Apex Toolkit

The Docusign Developer: Deep Dive Discussions video series covers basic to complex Docusign API use, as well as insights from our experts on best practices to speed up your development.

For the latest in this series, visit the Docusign Developer: Deep Dive Discussions YouTube playlist, sign up for our developer newsletter, and follow us on Twitter.

Additional Resources

• Docusign eSignature for Salesforce Essentials

• Docusign Apex Toolkit

• Using Bulk Send from the Apex Toolkit

• Docusign Developer Center

• @DocuSignAPI on Twitter

• Docusign for Developers on LinkedIn

• Docusign for Developers on Facebook

• Docusign Developer Newsletter

Neel Kumar is a Salesforce Engineering Manager for Docusign in charge of Salesforce integrations.

Lauren Dunne is our Senior Salesforce Evangelist and self-confessed Salesforce geek! She has nine years of Salesforce expertise and her past roles range from Solution Architect to “Admineloper.” She is currently a Salesforce MVP, the Ireland User Group leader, and founder and host of Ohana Coffee, a global virtual meet-up. She even has a Salesforce tattoo!