Using Docusign eSignature for Catalog Item Request

athavichith
Kilo Sage

‎06-27-2025 08:43 AM

Is it possible to import requested item variables to a PDF form and then send the form to the user to collect signature using Docusign eSignature spoke? 

 

I currently have the Docusign eSignature spoke configured and installed in my instance. 

 

Was curious to see if I can create variables to collect data and then transfer it to the form and then collec the signature. 

0 Helpfuls
  • 1,423 Views
2 REPLIES 2

pratikjagtap
Giga Guru

‎06-28-2025 09:04 AM

Hi @athavichith ,

 

I'm not sure its possible or not just try below steps :

1.Create a Fillable PDF

  • Use Adobe Acrobat to define field names like first_name, bank_name, etc.
  • Save the template.

2.Map RITM Variables to PDF Fields:

  • You’ll need to get the variables from the RITM using GlideRecord:

var ritm = new GlideRecord('sc_req_item');
ritm.get('sys_id_of_ritm');

var varBank = ritm.variables.bank;

 

3.Use DocuSign Action: Create Envelope with Document
From Flow Designer:

Action: DocuSign: Create Envelope with Document

Inputs:

  • PDF file (generated/populated beforehand)

  • Recipient email and name

  • Template fields mapping

4.

Use Tags (Tabs) for Signature Fields
Make sure your PDF has DocuSign tags or placeholders like \s1\ for the signature block, or use DocuSign's anchor tags or tabs.

Alternatively, use:

  • DocuSign: Add Recipients

  • DocuSign: Add Signatures
    … to define the fields dynamically.

5.Send Envelope and Track Status
Use DocuSign: Send Envelope action in the same Flow.

You can optionally use the spoke actions:

  • Get Envelope Status

    Get Completed Document

    Store the signed PDF as an attachment on RITM.

If my response helped, please hit the 👍Thumb Icon and accept the solution so that it benefits future readers.

 

Regards,
Pratik

0 Helpfuls

venkat917181
Tera Expert

‎06-28-2025 05:00 PM

Hey,

Yes, absolutely possible! I've actually implemented this exact scenario before and it works perfectly.

I used a business rule that calls a widget approach - the business rule triggers the process, then calls a widget to get the data, slice it, and merge it into a PDF before sending to DocuSign.

Why widget approach is better than direct field mapping: When field values are dynamically changing request-to-request (different catalog items, variable field counts, etc.), the widget handles this automatically without hardcoding field positions or names.

*****The beauty of this approach - YOU CAN DESIGN THE PDF HOWEVER YOU WANT! Just modify the widget HTML/CSS and you get completely custom PDF layouts. Professional forms, branded templates, multi-column layouts, tables, logos - whatever design you need.****

My implementation flow: Business Rule → Widget renders HTML with RITM variables → Convert HTML to PDF → Send via DocuSign

Code Snippets I Used:

Business Rule (After Insert/Update on RITM)

(function executeRule(current, previous) {
    if (current.state == 'pending_signature') {
        var pdfGen = new RITMPDFGenerator();
        pdfGen.processRequest(current.sys_id.toString());
    }
})(current, previous);

Script Include for PDF Generation

var RITMPDFGenerator = Class.create();
RITMPDFGenerator.prototype = {
    
    processRequest: function(ritmId) {
        // Get widget HTML with RITM data
        var widgetHTML = this.getWidgetHTML(ritmId);
        
        // Convert to PDF
        var pdfBytes = this.convertToPDF(widgetHTML);
        
        // Send to DocuSign
        this.sendToDocuSign(pdfBytes, ritmId);
    },
    
    getWidgetHTML: function(ritmId) {
        var widget = new $sp.getWidget('ritm-pdf-template');
        widget.options = {ritm_id: ritmId};
        return widget.getHTML();
    }
};

Widget Server Script

(function() {
    // Get RITM data
    data.ritm = {};
    data.variables = [];
    
    if (options.ritm_id) {
        var ritmGR = new GlideRecord('sc_req_item');
        ritmGR.get(options.ritm_id);
        data.ritm = ritmGR;
        
        // Get all variables dynamically
        var varGR = new GlideRecord('sc_item_option_mtom');
        varGR.addQuery('request_item', options.ritm_id);
        varGR.query();
        
        while (varGR.next()) {
            var option = varGR.sc_item_option.getRefRecord();
            data.variables.push({
                name: option.name.toString(),
                label: option.question_text.toString(),
                value: varGR.sc_item_option.value.toString(),
                display_value: varGR.sc_item_option.display_value.toString()
            });
        }
    }
})();

Widget HTML Template

<div class="ritm-pdf-container">
    <h2>{{::data.ritm.cat_item.getDisplayValue()}} Request</h2>
    <div class="request-details">
        <p><strong>Requested for:</strong> {{::data.ritm.opened_for.getDisplayValue()}}</p>
        <p><strong>Request Number:</strong> {{::data.ritm.number}}</p>
    </div>
    
    <div class="variables-section">
        <h3>Request Details</h3>
        <div ng-repeat="variable in ::data.variables" class="variable-row">
            <label>{{::variable.label}}:</label>
            <span>{{::variable.display_value}}</span>
        </div>
    </div>
    
    <div class="signature-section">
        <p>Signature: _________________________</p>
        <p>Date: _______________</p>
    </div>
</div>

Fair warning - this approach is a little bit complex to set up initially, but it's the perfect solution for dynamic scenarios like yours. The widget dynamically pulls all RITM variables and formats them cleanly, handles any catalog item changes automatically without touching the business rule code.

Much more robust than trying to map static PDF fields, especially when you have varying request types with different variable sets.

Let me know if you want more details on the DocuSign integration part!

Thanks

 

0 Helpfuls