by faysal
ServicesSolutionsWorkPluginsBlogContact

by Faysal

AI Automation & Software Developer

hello@byfaysal.com

Navigate

ServicesSolutionsWorkBlogPluginsGuidesAboutResumeContactTools I Use

Services

Ecommerce PlatformsWordPress SolutionsWeb ApplicationsAutomationAI Solutions

From the Blog

WooCommerce vs ShopifyI Built a SaaS SoloZapier vs Make vs N8NView all articles →

Connect

EmailGitHubYouTubeInstagramLinkedInXUpworkFiverr

by Faysal

© 2026 Mostafa Faysal. Systems built with intention.

Privacy PolicyTermsAffiliate Disclosure
  1. Home
  2. /Blog
  3. /How I Automated DocuSign With WordPress and Eliminated Manual Document Processing

wordpress · 14 min · 2026-06-10

How I Automated DocuSign With WordPress and Eliminated Manual Document Processing

A WordPress plugin that connects Gravity Forms to DocuSign API with per-user state tracking, automatic follow-ups, and Multisite inheritance. Zero manual intervention.

How I Automated DocuSign With WordPress and Eliminated Manual Document Processing — featured imagewordpress

TL;DR: A client's team was manually sending DocuSign envelopes from form submissions, tracking signing status in spreadsheets, and chasing follow-ups by hand — across a WordPress Multisite network. I built a custom WordPress plugin that connects Gravity Forms to the DocuSign API, automatically sends envelopes, tracks per-user per-document signing status, sends intelligent follow-up emails on configurable schedules, and inherits across the entire Multisite network with zero configuration. The result: zero manual intervention from form submission to signed document.

Short answer: I replaced a workflow that required 15-20 minutes of staff time per document signing with a system that takes zero seconds. The client fills out a form, DocuSign sends the envelope, the system tracks who has signed and who has not, and follow-up reminders go out automatically. Built as a WordPress plugin in 2 months.

This is not a glamorous project. It does not have a flashy UI or AI models. But it represents what business automation actually looks like for most organizations — taking a painful manual process and making it disappear completely.

The Manual Process That Was Killing Productivity

What the Staff Was Doing Before

The client ran a WordPress Multisite network. Multiple sub-sites, multiple teams, multiple document types. The document signing workflow looked like this:

  1. A user fills out a Gravity Form on one of the sub-sites
  2. Staff member gets an email notification about the submission
  3. Staff member opens DocuSign, creates a new envelope manually
  4. Staff member copies data from the form submission into DocuSign template fields
  5. Staff member adds signers (sometimes multiple parties for a single document)
  6. Staff member sends the envelope
  7. Staff member logs the document status in a shared spreadsheet
  8. Staff member checks DocuSign periodically for signing status updates
  9. If a signer has not signed within a few days, staff member sends a follow-up email manually
  10. When the document is fully signed, staff member updates the spreadsheet and notifies relevant parties

For a single document, this takes 15-20 minutes of focused work. For an organization processing dozens of documents per week across multiple sites, this workflow consumed hours of staff time daily.

The real cost was not just the labor — it was the errors. Missed follow-ups meant documents sat unsigned for weeks. Copy-paste errors meant signer information was wrong. Spreadsheet tracking was inconsistent across teams. And every time a new sub-site was added to the Multisite network, the workflow had to be manually set up again.

What the Client Needed

The requirements were simple to state and hard to build:

  1. When a Gravity Form is submitted, automatically create and send a DocuSign envelope
  2. Map form fields to DocuSign template placeholders (different templates per form type)
  3. Handle documents with multiple signers
  4. Track the signing status of each signer for each document
  5. Send automatic follow-up emails to signers who have not signed
  6. Work across the entire WordPress Multisite network without per-site configuration

The Architecture: WordPress Plugin + DocuSign API

Why a WordPress Plugin (Not Zapier)

I covered when to use custom integration vs. Zapier in detail in another post. The short version for this project:

Stateful per-user tracking eliminates Zapier. This workflow is not a simple trigger-action. The system needs to know: "User A submitted Form X on Site 3. The document requires two signers. Signer 1 has signed. Signer 2 has not signed and was sent a reminder 3 days ago. Another reminder is due tomorrow." Zapier does not maintain state across tasks. It processes each event independently with no memory of previous events.

Multisite inheritance eliminates SaaS platforms. The plugin needs to activate at the network level and automatically work on every sub-site. This is a WordPress-specific capability that no external automation platform can replicate.

Volume and cost. The client processes enough documents that Zapier's per-task pricing would exceed the one-time development cost within 6-8 months.

The Plugin Architecture

The plugin has four core components:

┌─────────────────────────────────────────────────┐
│            DocuSign Automation Plugin            │
├─────────────────────────────────────────────────┤
│                                                  │
│  1. FORM HANDLER                                │
│     └── Hooks into Gravity Forms submission     │
│     └── Extracts signer data and field mapping  │
│     └── Triggers envelope creation              │
│                                                  │
│  2. DOCUSIGN API CLIENT                         │
│     └── OAuth2 authentication with token refresh│
│     └── Envelope creation and sending           │
│     └── Status polling and webhook handling     │
│                                                  │
│  3. STATE TRACKING ENGINE                       │
│     └── Per-user, per-document status records   │
│     └── State machine: sent → viewed → signed   │
│     └── Audit trail with timestamps             │
│                                                  │
│  4. FOLLOW-UP SCHEDULER                         │
│     └── WordPress Cron-based reminder system    │
│     └── Configurable intervals and templates    │
│     └── Escalation rules for unsigned documents │
│                                                  │
└─────────────────────────────────────────────────┘

Component 1: Form Handler

The form handler hooks into Gravity Forms' gform_after_submission action. When a form is submitted, it:

  1. Checks whether this form has a DocuSign mapping configured (not all forms trigger document signing)
  2. Extracts signer information from the form fields (name, email, role)
  3. Extracts document data from form fields (values that populate the DocuSign template)
  4. Maps form fields to DocuSign template tabs (text fields, checkboxes, signature locations)
  5. Passes everything to the DocuSign API client

The mapping configuration is stored as form metadata — the admin configures which form fields map to which DocuSign template placeholders through a settings interface on each form.

// Simplified form submission handler
add_action('gform_after_submission', 'process_docusign_submission', 10, 2);

function process_docusign_submission($entry, $form) {
    $mapping = get_docusign_mapping($form['id']);
    if (!$mapping) return; // No DocuSign mapping for this form

    // Extract signer data based on field mapping
    $signers = extract_signers($entry, $mapping);
    $template_data = extract_template_data($entry, $mapping);

    // Create and send DocuSign envelope
    $envelope_id = create_docusign_envelope(
        $mapping['template_id'],
        $signers,
        $template_data
    );

    // Initialize state tracking for each signer
    foreach ($signers as $signer) {
        create_tracking_record(
            $envelope_id,
            $signer['email'],
            $entry['id'],
            get_current_blog_id()
        );
    }
}

Component 2: DocuSign API Client

The DocuSign API uses OAuth2 with JWT bearer tokens for server-to-server authentication. The implementation handles:

Token management. Access tokens expire after 1 hour. The client checks token validity before each API call and refreshes automatically when needed. Tokens are stored in WordPress options with expiry timestamps.

Envelope creation. Each form submission creates a new envelope from a predefined DocuSign template. The template ID is configured per form. Template tabs (fields) are populated with data from the form submission.

Status tracking. DocuSign provides two mechanisms for tracking signing status: polling (requesting status on a schedule) and webhooks (DocuSign pushes status changes to your endpoint). I implemented polling via WordPress Cron because it is simpler to deploy on WordPress hosting and does not require a publicly accessible webhook endpoint, which some WordPress Multisite configurations make difficult.

function check_envelope_status($envelope_id) {
    $client = get_docusign_client();
    $response = $client->get_envelope_status($envelope_id);

    foreach ($response['recipients'] as $recipient) {
        update_tracking_record(
            $envelope_id,
            $recipient['email'],
            $recipient['status'], // sent, delivered, signed, declined
            $recipient['signed_date_time'] ?? null
        );
    }

    return $response['status']; // sent, delivered, completed, declined, voided
}

Component 3: State Tracking Engine

This is the component that makes the system work — and the one that no automation platform can replicate cleanly.

Every signer for every document has a tracking record in a custom database table:

CREATE TABLE wp_docusign_tracking (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    envelope_id VARCHAR(255) NOT NULL,
    signer_email VARCHAR(255) NOT NULL,
    signer_name VARCHAR(255),
    form_entry_id BIGINT NOT NULL,
    site_id BIGINT NOT NULL,
    status ENUM('pending', 'sent', 'delivered', 'viewed', 'signed', 'declined') DEFAULT 'pending',
    sent_at DATETIME,
    viewed_at DATETIME,
    signed_at DATETIME,
    last_reminder_at DATETIME,
    reminder_count INT DEFAULT 0,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    UNIQUE KEY unique_signer_doc (envelope_id, signer_email)
);

The site_id column is critical for Multisite. It tracks which sub-site the document originated from, enabling per-site reporting and per-site admin views without any cross-site data leakage.

The state machine is simple but strict:

pending → sent → delivered → viewed → signed
                                    → declined

Status transitions only move forward. A signed document cannot move back to "viewed." A declined document cannot be changed to "signed." This prevents data integrity issues from API polling inconsistencies or duplicate webhook deliveries.

Component 4: Follow-Up Scheduler

The follow-up system uses WordPress Cron to check for unsigned documents on a schedule (typically daily) and send reminder emails.

The follow-up rules are configurable:

  • First reminder: 3 days after sending (configurable)
  • Second reminder: 7 days after sending
  • Escalation: 14 days after sending — notify the admin that the document remains unsigned
  • Maximum reminders: 3 (configurable) — do not harass signers endlessly
// Scheduled follow-up check (runs daily via WP-Cron)
function process_pending_followups() {
    $unsigned = get_unsigned_documents(
        min_age_days: 3,
        max_reminders: 3
    );

    foreach ($unsigned as $record) {
        $days_since_sent = days_between(now(), $record->sent_at);
        $days_since_last_reminder = days_between(now(), $record->last_reminder_at);

        $schedule = get_followup_schedule($record->site_id);

        if (should_send_reminder($days_since_sent, $days_since_last_reminder, $record->reminder_count, $schedule)) {
            send_followup_email($record);
            update_reminder_count($record->id);
        }

        if (should_escalate($days_since_sent, $schedule)) {
            notify_admin_unsigned($record);
        }
    }
}

The follow-up emails are WordPress-templated, meaning they respect the site's email branding and can be customized per sub-site in the Multisite network.

The Multisite Challenge

The Problem With WordPress Multisite and Custom Tables

WordPress Multisite creates separate database tables for each sub-site (prefixed with wp_2_, wp_3_, etc.). Custom plugins need to decide: create tables per site or use a single shared table?

Per-site tables mean the plugin needs to create the tracking table on every site activation, handle table creation when new sites are added, and manage schema migrations across dozens of tables.

A single shared table with a site_id column is simpler to manage but requires careful query scoping to prevent cross-site data leakage.

I chose the shared table approach with strict site_id filtering on every query. This means:

  • One table to manage, one schema to migrate
  • All queries include WHERE site_id = %d as a mandatory filter
  • Admin views are automatically scoped to the current site
  • Network-level admins can see data across all sites

Network Activation

The plugin supports network activation — activate once at the network level, and it works on every sub-site immediately. New sub-sites added later automatically inherit the plugin's functionality.

This required hooking into WordPress Multisite's wpmu_new_blog action to ensure the DocuSign configuration propagates correctly and the tracking table includes the new site's data scope.

The Results

Before Automation

MetricValue
Time per document15-20 minutes of staff time
Follow-up trackingManual spreadsheet, inconsistent
Error rate~5% (wrong signer info, missed follow-ups)
New site setupManual configuration per sub-site
Time from form to envelope1-4 hours (depends on staff availability)

After Automation

MetricValue
Time per document0 minutes of staff time
Follow-up trackingAutomatic, 100% coverage
Error rate0% (data comes directly from form submission)
New site setupAutomatic (Multisite inheritance)
Time from form to envelopeUnder 30 seconds

The most impactful metric is not the time savings — it is the elimination of missed follow-ups. Before automation, documents would sit unsigned for weeks because nobody remembered to send a reminder. After automation, every unsigned document gets a reminder on schedule, every time.

What Makes This Different From a DocuSign Zapier Integration

Zapier has a DocuSign integration. You can trigger a Zapier workflow when a form is submitted and send a DocuSign envelope. Here is why the custom plugin does what Zapier cannot:

CapabilityCustom PluginZapier
Per-user signing status trackingFull state machine in databaseNo persistent state — each task is independent
Automatic follow-up remindersConfigurable schedule with escalationWould need separate Zaps + external state tracking
Multi-signer coordinationTracks each signer independently, knows composite stateCannot correlate multiple webhook events for the same envelope
WordPress Multisite supportNetwork-activated, per-site scopingNo concept of Multisite
Admin dashboard in WordPressFull reporting, per-site views, status managementData lives in Zapier, not your admin
Cost at scale$0/month (runs on existing hosting)$50-$200+/month depending on volume

The custom plugin cost more to build. But it does things Zapier cannot do, runs inside the admin where staff already work, and costs nothing to operate month over month.

What I Would Do Differently

Add Webhook Support From Day One

I used polling (WordPress Cron checking DocuSign status every few hours) instead of DocuSign webhooks (real-time push notifications). Polling works but introduces a delay — the system might not know a document was signed until the next polling cycle.

Webhooks would provide instant status updates. I chose polling initially because the client's WordPress Multisite configuration made exposing a public webhook endpoint complicated (multiple sites, one URL). In hindsight, a single webhook endpoint at the network level that routes events to the correct site based on envelope metadata would have been cleaner.

Build a Visual Pipeline View

The admin interface shows a table of documents with their current status. A visual pipeline view — showing documents flowing through stages with drag-and-drop for manual intervention — would make the workflow more intuitive for non-technical staff.

Add PDF Storage

Completed documents are stored in DocuSign. Adding automatic download and storage of signed PDFs in the WordPress media library (or a connected cloud storage service) would give the client a local archive without depending on DocuSign's retention policy.

Frequently Asked Questions

How much does a DocuSign WordPress automation cost to build?

A basic integration (form → DocuSign envelope, one signer, no status tracking) costs $2,000-$4,000. A full system with multi-signer support, state tracking, automatic follow-ups, and Multisite compatibility costs $6,000-$12,000. The ongoing cost is $0/month beyond existing hosting, compared to $50-$200+/month for equivalent Zapier-based automation.

Can I use WPForms or Contact Form 7 instead of Gravity Forms?

Yes — the DocuSign API integration is not Gravity Forms-specific. The form handler hooks into the form plugin's submission action. Different form plugins use different hooks, but the downstream logic (envelope creation, state tracking, follow-ups) is identical. Gravity Forms was used because the client already had it and it offers the most robust field mapping options.

Does this work with DocuSign's free plan?

DocuSign's free Developer plan is limited to 20 envelopes per month. For testing and development, it works. For production use with significant document volume, you need a paid DocuSign plan ($10-$40+/month per user). The plugin works with any DocuSign plan — it uses the same API regardless of plan tier.

Can this approach work for other document signing services?

Yes. The architecture — form handler, API client, state tracking, follow-up scheduler — is the same regardless of the signing service. Swapping DocuSign for Adobe Sign, HelloSign, or PandaDoc requires replacing the API client component while keeping the rest of the system intact. The state tracking and follow-up logic are signing-service-agnostic.

How reliable is WordPress Cron for automated follow-ups?

WordPress Cron is triggered by site visits, not by a system clock. On low-traffic sites, Cron jobs may be delayed. The solution is a server-level Cron job that hits wp-cron.php on a schedule (every 15 minutes is standard). With this setup, follow-ups are sent within 15 minutes of their scheduled time, which is precise enough for document reminders. For the client's active Multisite network with consistent traffic, WordPress Cron fires reliably.


Drowning in manual document workflows? I build automation systems that eliminate repetitive work — from DocuSign integrations to custom API workflows to full business process automation. If your team spends hours on tasks that should take seconds, book a free automation assessment to find out what can be automated, or explore my automation services.

Mostafa Faysal

Mostafa Faysal

Systems developer who builds ecommerce platforms, business automation, and SaaS products. 15+ production systems shipped.

→ Get a free audit→ See automation-integration service