Leegality revamps platform from the ground up — launches Workflow 4.0

Summary

Traditional eSign platforms only handle execution, ignoring the complex realities of real-world enterprise workflows. Leegality 4.0 workflows addresses these operational gaps through four key features: 

  • Doc Packs: Enables sending multiple separate documents as a single pack under a single eSign link, while retaining individual document-level configurations, stamp duties, and audit trails.
  • Custom Workflow Fields: Offers fully governable and configurable fields per workflow to define data visibility, mandatory fields, and validation rules.
  • Rule Engine: Encodes organizational business and compliance SOPs directly into the workflow with conditional rules and auto-calculated stamp duty values.
  • Leegality Automation Module (LAM): Automates interactions with external systems during execution using native third-party connectors, event-based triggers, and sequence building.

Today we are launching Workflow 4.0 — an evolution of Leegality from an eSign/eStamp platform to a complete document workflow platform.

What is the difference between an eSign/eStamp platform and a document workflow platform?

An eSign/eStamp platform solves the execution of the document. But it does not solve the surrounding workflow that the document encapsulates.

An eSign/eStamp platform sees a home loan agreement workflow like this:

eSign/eStamp platform

You pass the document, it gets eSigned and eStamped, and the executed document comes back.

This is a crude distortion of the reality of a document workflow. A real document workflow is a varied orchestration of variables, SOPs and systems — with eSign/eStamp being a key component but not the whole thing.

Let's walk through what a real home loan workflow actually involves.

First — it's not one document, it's a pack. A home loan agreement workflow does not just consist of a “single” home loan document. It involves a Loan Agreement, KFS, Sanction Letter, Mortgage Deed and DPN. Each document needs its own stamp duty, its own signers, its own eSign type. But eSign/eStamp platforms are built around a single PDF — so teams either merge everything into one rigid PDF and lose document-level control, or send multiple signing links and increase drop-offs.

Second — every element of each document's treatment needs to be configurable and governed. Each document in the kit has dozens of configurations — which eSign type to use, whether face capture is on, what stamp duty to apply, which fields are editable by a runner and which are locked, what business identifiers to attach. An eSign platform gives you a fixed set of options with no way to validate inputs or control what a runner can and cannot change. So either your teams compensate manually, or you build middleware to do it.

Third — the same workflow needs to run differently based on your SOPs: The document kit and its configurations don’t remain static. They change on a case-by-case basis depending on the specifics of the transaction — and what your SOPs say about it. For example, a ₹50 crore housing loan in Maharashtra and a ₹20 lakh housing loan in Karnataka are both “housing loan agreement workflows”, but both require different things — the ₹50 crore loan may require a stronger eSign and higher stamp duty while the ₹20 lakh one may require a simpler eSign and no stamp duty. Essentially the way a document workflow runs is determined by your organization’s business and compliance SOPs. An eSign/eStamp platform has no way to encode these SOPs. To solve this you either build multiple workflows and orchestrate this via middleware, or you rely on manual enforcement each time.

Fourth — the workflow doesn't complete in isolation. A document workflow is part of a wider transaction. It needs data from other systems to start correctly, it may need to trigger actions in other systems during execution, and it needs to send results back when done. An eSign platform is a closed box — data goes in before execution, executed document comes out after. It has no ability to interact with the systems around it while the workflow is running. So your engineering team builds and maintains the connections externally.

So the reality of a home loan workflow — with an eSign/eStamp platform — looks like this:

Home loan workflow

eSign/eStamp platform handles execution — a small, albeit critical, component. The rest of the orchestration — the kit, the field governance, the SOP enforcement, the system connections — has to be managed by you. To do this you either build it yourself — spending significant IT resources — or rely on your LOS/LMS/CRM partner, who is already swamped with 10 other requests.

As a result, your cost of deploying a document workflow increases while also being delayed.

This is why — despite 10 years of eSign — most document workflows in Indian BFSI are still paper-based.

We decided to solve for this — hence 4.0.

What 4.0 does

4.0 brings each of those four dimensions inside the workflow:

Doc Packs — send multiple separate documents together as a pack in a single eSign link. Each document retains its own eSign configuration, stamp requirements and audit trail. The signer receives one link, eSigns each document in one session, and every document is executed and stored separately.

Custom Workflow Fields — every field in the workflow becomes configurable and governable. Control what's visible, editable, mandatory and valid — per field, per workflow. Add your own business fields (Loan ID, Branch Code), set validation rules so incorrect data gets caught before the workflow is sent, and lock down what a runner can and cannot change. The workflow enforces exactly what the process requires.

Rule Engine — configure your SOPs directly into the workflow as rules. Conditional rules: if loan > ₹2L, use Aadhaar eSign. Auto-calculated values: stamp duty = f(state, article code, loan amount), computed every time. One workflow handles all permutations — no multiple workflows, no middleware, no manual enforcement.

LAM (Leegality Automation Module) — the workflow calls external systems during execution, natively. Three components: Third Party Connectors (data in and out), Event Based Automation (trigger actions when document state changes), Sequence Builder (chain systems and Leegality actions together in a flow).

With 4.0, the home loan workflow looks like this:

Leegality 4.0

What this changes:

We run the entire workflow — not just the execution. The kit, the per-document treatment, the SOPs, the system connections — it all lives inside one workflow that you configure on Leegality

It's self-serve. When SOPs change, stamp duty rules update or you need to add a new document, you configure it on the dashboard via the Rule Engine. You no longer need to make feature requests to us or ask your IT team. 

No more middleware. Your engineering team no longer builds and maintains the logic bridging what your process requires and what Leegality can do. 

eSign/eStamp platforms do not solve the needs of Indian enterprise. A document workflow platform does.

To put it simply — there are many ways to collect a payment (UPI, Credit Card, Netbanking). But for an Indian enterprise to actually run payments, a payments platform also reconciles, detects fraud, routes and handles the front-end. If your payments provider did not do this, you would probably not stick with them.

eSign/eStamp in this scenario is payment collection. A document workflow platform - which is what Leegality 4.0 is –  is the complete payments stack.

Leegality 4.0