Documents are rebuilt by hand from CRM data
Someone opens the record, then retypes the client name, the amount, the dates and the terms into a Word file. Every retype is a chance to send a customer the wrong number.
Salesforce · Document Generation & eSignature
Lumin consulting and implementation, built around your Salesforce workflow
Lumin turns a Salesforce record into a document your customer can sign — template, merged data, signer routing and status, without leaving the CRM. The hard part is never the app. It is the data model the templates read from, the automation that decides when a document goes out, and the fields that have to be right when it comes back signed. We implement Lumin, configure it around your process, and build the Salesforce work underneath it.
12+
250+
500+
40+
Trusted by 500+ organizations — including real estate, professional services and technology teams running document and signature workflows on Salesforce with Twopir Consulting.
Built for Document Operations
- Salesforce Partner
- Lumin Sign
- Document Generation
- eSignature Workflows
- Salesforce Flow
- CPQ & Quoting
- Real Estate
- Professional Services
Where document workflows break down
Almost nobody buys document software because documents are interesting. They buy it because a deal, a lease or an onboarding is sitting still while someone rebuilds a file by hand. These are the six failures we are usually called in to fix.
The same template exists in six versions
Masters live on desktops and in shared folders. Legal approves one wording change and three older versions stay in circulation, because nothing controls which file a user starts from.
Approval and sending stay manual
The document is finished, then it waits — for a manager to eyeball it, for someone to attach it to an email, and for somebody to remember to chase it three days later.
Signature status lives in an inbox
"Has the client signed yet?" should be a field on a record. When the only answer is in somebody's mail client, forecasting, handoffs and revenue recognition all inherit the delay.
Signed documents never return to the record
The executed PDF lands in a drive folder instead of on the account it belongs to. Renewals, audits and disputes then start with a search rather than a click.
The process does not survive volume
What one operations person holds together at twenty documents a week falls apart at two hundred, across several teams, regions, entities and document types.
Lumin Consulting & Implementation Overview
What Lumin is, and who it is for
Lumin is a document platform built around PDF editing, agreement creation and electronic signature. Lumin Sign is its agreement and signing workflow product; Lumin for Salesforce — the AppExchange application, also published as Lumin Sign for Salesforce — runs natively inside Salesforce so a user can build a document from a record, send it for signature, and track it back to that record without leaving the CRM. A separate Lumin Sign API exists for teams embedding signing into their own product. Vendor documentation: luminpdf.com/lumin-sign.
It fits organisations whose documents are repetitive, data-driven and customer-facing — listing and buyer agreements, proposals, quotes, service agreements, onboarding packs, renewals. We help growing and mid-market companies solve complex CRM, integration and business system challenges, and we work with enterprise organisations on the same problems at larger scale. The buyers on this page are usually revenue operations leads, CRM managers, Salesforce admins and architects, and the business owner of whatever document is slowing a process down.
It is worth being clear about the boundary. Lumin produces and executes documents; it is not a contract lifecycle management suite, and it is not a data model. Whether the right clause, the right price and the right signer appear on a generated document is a function of how your Salesforce data is structured and governed — which is the part most implementations underestimate, and the part Twopir Consulting is engaged to get right.
Implement, configure, or build on top of Lumin
These are three different engagements with three different budgets and three different buyers, and confusing them is how document projects overrun. Here is exactly where each one starts and stops.
| Engagement | What it covers | When you need it | Where it stops |
|---|---|---|---|
| Implement Lumin | Install and connect the app, set the licence and permission model, place it on the right Lightning pages, build the first template set, and roll out from a sandbox with a documented admin runbook. | You have bought Lumin, or are about to, and need it live and trusted rather than installed and ignored. | Standard product behaviour, configured. No custom code. |
| Configure Lumin around your process | Template and merge-field design, conditional content by region or entity, signer routing and order, Flow-triggered sends, approval before send, reminder cadence, and status write-back to the record. | The app works but the process does not — wrong people signing, wrong clauses appearing, or status that nobody can report on. | Declarative Salesforce work: Flow, fields, validation, page layouts, permissions. |
| Build on Lumin | Apex and Lightning Web Component work, Lumin Sign API and webhook integration, middleware to other systems, multi-object document packages, and bulk or scheduled generation. | Your requirement is outside what configuration can express — volume, a custom UI, or another system in the chain. | Scoped, tested custom development with a defined support model. |
The dividing line we use: if the requirement can be expressed in fields, templates, Flow and permissions, it is configuration. The moment it needs code to run, an external system to respond, or a screen the platform does not provide, it is development — and we say so before the estimate, not during the build.
What a Lumin engagement actually delivers
Lumin supplies the document engine and the signing workflow. Everything below is the work we do so that engine produces the right document, for the right signer, at the right moment in your Salesforce process.
Lumin Implementation on Salesforce
Getting the application live in a way your administrators can own — installed, scoped, permissioned and documented, not dropped into production and explained in a call.
- AppExchange install and connected-app authorisation
- Licence allocation and permission-set design
- Lightning record page and action placement
- Sandbox-first build with a staged production rollout
- Admin runbook and internal ownership handover
Template & Document Design
An inventory of every document you actually send, rationalised into one approved, versioned set that legal signs off once instead of chasing forever.
- Document inventory and template rationalisation
- Merge-field mapping to Salesforce fields and related lists
- Conditional content by region, entity or deal type
- Brand and legal-approved master templates
- Version governance and change control
- Multi-document packages sent as one action
Salesforce Data Mapping & Model Work
A generated document is only as accurate as the record behind it. This is the least visible part of a Lumin project and the one that decides whether people trust the output.
- Field audit against every merge point in the templates
- Formula and roll-up fields to supply derived values
- Relationship and junction-object design for multi-party agreements
- Validation rules so documents cannot generate from incomplete records
- Picklist and reference-data governance
- Data cleanup ahead of first generation
Workflow & Automation Configuration
Deciding when a document goes out, who approves it, who signs first, and what the record looks like afterwards — expressed in Salesforce automation rather than in habits.
- Record-triggered and screen Flows that generate and send
- Approval steps before anything reaches a customer
- Signer routing, signing order and counter-signature
- Reminder and expiry cadence
- Status write-back to stage, fields and tasks
- Renewal and re-signature triggers on date fields
Integration & Custom Development
When configuration runs out — high volume, a bespoke interface, or another system that has to know a document was signed — we build and support the code.
- Lumin Sign API and webhook integration
- Apex and Lightning Web Components for custom generation screens
- Bulk and scheduled document generation
- Connections to ERP, billing, HR and property systems
- Google Drive and Microsoft OneDrive document routing
- Middleware where a direct integration is the wrong answer
Optimization, Support & Migration
For teams already on Lumin, or moving to it from another signing tool, with templates and history that cannot simply be abandoned.
- Assessment of an existing Lumin configuration
- Template consolidation and failure-rate reduction
- Migration from another eSignature or document application
- Permission and security review
- User enablement and adoption support
- Ongoing retained optimisation as volumes grow
The documents teams put through Lumin first
Most organisations do not automate everything at once. They start with the one document that is costing them the most time, prove it, then extend. These are the starting points we see most often.
| Document | Generated from | What the workflow does | What changes |
|---|---|---|---|
| Listing & buyer agreements | A property or listing record reaching an agreed stage | Merges the parties, the property details and the commission terms, then routes to each signer in order | Agents send from the record they are already in, and the executed agreement returns to it |
| Proposals & statements of work | An opportunity moving to proposal stage | Builds from one approved master and merges scope, pricing and dates from the record | One version of the proposal exists, and the pricing on it matches the pipeline |
| Quotes & order forms | A quote or CPQ quote record | Produces the customer-facing document from current line items and discount approvals | Nobody re-keys pricing between the quote record and the PDF |
| Service agreements & MSAs | An account or contract record | Applies conditional clauses by region, entity or product mix before sending | Legal-approved language is applied by rule instead of by editing |
| Customer onboarding packs | An opportunity marked Closed Won | Generates and sends several documents as a single package with one signing experience | Onboarding starts the day the deal closes, not the week after |
| Renewals & amendments | A contract with an approaching end date | Regenerates the agreement from current record values and routes it for signature | Renewal paperwork stops being a manual rebuild of last year's file |
| Operational & vendor paperwork | A supplier, contractor or internal request record | Sends a standard packet and tracks completion centrally | Back-office paperwork is tracked with the same discipline as revenue paperwork |
The architecture underneath a Lumin document
A document workflow touches your data model, your automation, your storage and your security model at once. These are the eight surfaces we design against on a Lumin project.
Salesforce Objects & Data Model
Templates read from Account, Contact, Opportunity, Quote, Contract and your custom objects. Fields missing on the record are missing on the document — so the model is designed before the template is.
Salesforce Flow & Automation
Record-triggered and screen Flows decide when a document is generated and sent. Signature events flow back the other way, updating stage, fields and tasks so the record leads the process.
Salesforce CPQ & Quoting
Quote line items, discounts and approved pricing move from the quote record into the customer-facing document, so what the customer signs is what the pipeline already says.
Files, Content & Retention
Executed documents are written back to Salesforce Files against the right parent record, with a naming and retention convention agreed up front rather than invented per user.
Google Drive & Microsoft OneDrive
Where a team's documents of record live outside Salesforce, signed files are routed into the correct Drive or OneDrive location as well, so neither system becomes the incomplete one.
Lumin Sign API & Webhooks
For embedded or high-volume signing, Lumin publishes an API and webhook events. We consume those events server-side so downstream systems react to a signature without polling for it.
Security, Sharing & Permissions
Who may generate, who may send, who may see an executed document. Permission sets, sharing rules and field-level security are designed with the workflow, not retrofitted after an incident.
Reporting & Audit Trail
Signature status stored on the record makes turnaround time, stalled documents and completion rates reportable in Salesforce — alongside the audit trail Lumin keeps for each signed document.
Twelve stages, six phases, one accountable team
A Lumin project is not a software install with training bolted on the end. Each phase exists because skipping it produces a specific, predictable failure — and we have seen each of them.
Discovery & Current-State Assessment
Stages 1–2. We collect every document you send, who touches it, how long each step takes, and where it is re-keyed. Without this, template design becomes guesswork and the project automates the wrong thing efficiently.
Solution Architecture & Data Design
Stage 3. We decide which object each document generates from, which fields feed each merge point, and what has to exist before generation is allowed. This is where most of the eventual quality is determined.
Lumin Configuration & Template Design
Stages 4–5. The app is installed, licensed and permissioned, and the approved template set is built with conditional content and correct merge mapping. Legal reviews once, against a master, not repeatedly against drafts.
Integration, Automation & Customization
Stages 6–8. Flows generate and send, approvals gate what reaches customers, signature events write back, and anything beyond configuration is built as scoped code with a defined support model.
Testing, Validation & Training
Stages 9–10. Every template is tested against real records, including the awkward ones — missing fields, multiple signers, unusual entities — and users are trained on their own documents rather than a demo.
Deployment, Support & Optimization
Stages 11–12. A staged go-live, then the quarters that matter: monitoring failed generations, retiring templates nobody uses, and extending to the next document type once the first is trusted.
What changes once the document workflow runs itself
We do not publish a percentage for a project we have not measured. What we will commit to is the shape of the change — and we agree the baseline with you during discovery so the improvement is measurable rather than asserted.
Less manual assembly
Documents are produced from the record instead of rebuilt from it, which removes the copy-and-paste step entirely rather than making it faster.
Faster turnaround to signature
Generation, approval and sending become one triggered sequence, so the gap between "we agreed" and "they signed" stops depending on who is at their desk.
Fewer errors on customer documents
Merge fields and validation rules replace human transcription, so the price, the party and the dates on the document match the record by construction.
Consistent, approved formats
One governed template set means every customer sees the same current wording, and a legal change is made in one place instead of chased across six files.
Status visible where the work happens
Signature state on the record makes stalled documents reportable, so managers chase from a dashboard instead of asking the team in a stand-up.
Document operations that scale
Adding a region, an entity or a document type becomes a configuration change rather than another manual process and another person to run it.
Document automation we have already delivered
These three engagements were delivered on Salesforce with other document applications, and we say so deliberately. The architecture work behind them — data mapping, template governance, triggered generation, status write-back — is the same work a Lumin implementation needs. Each figure below is scoped to the engagement that produced it.
Enterprise Software Company
Automated document generation on Salesforce with PDF Butler, removing manual quote assembly.
45% Reduction in sales operations time
Real Estate Company
Salesforce operations, lead management and document workflows automated end to end.
50% Acceleration in deal closures
Property Management Firm
Property operations and paperwork consolidated with Propertybase on Salesforce.
40% Reduction in manual workload
A Lumin project is a Salesforce project
Anyone can install an AppExchange application. The reason document projects disappoint is almost never the application — it is the data, the process design and the automation around it, which is where our practice actually sits.
We start with the data model, not the template
A beautiful template over a weak record produces a confident, wrong document. We audit the fields behind every merge point first, and we will tell you when the honest first phase is data work rather than document work.
We name the configuration and development boundary up front
Before the estimate, you get a written split of what is configuration and what needs Apex, an API or a custom component — with the cost and support implications of each. Scope surprises on document projects nearly always hide in that gap.
We have built document automation on more than one platform
Our team has delivered Salesforce document and signature work with Conga Composer implementation, Nintex DocGen for Salesforce, S-Docs native document generation and DocuSign integration services. That comparison is useful to you: we can say where Lumin is the right fit and where it is not.
We work at the size you actually are
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. A twelve-template rollout for one region and a multi-entity programme get the same architecture discipline at different scale.
We stay past go-live
Document workflows degrade quietly — a field is renamed, a template stops merging, a signer list goes stale. We monitor generation failures and template usage after launch, and treat the first two quarters as part of delivery.
Where this work connects
A document workflow rarely arrives alone. These are the pages most Lumin conversations end up touching.
Document Generation & eSignature
Salesforce Practice
Answers before the first call
Six phases: discovery of the documents you actually send, architecture of the data behind them, installation and template design, automation and integration, testing and user training, then deployment with post-launch optimisation. Installing the application is a small part of it. Most of the effort goes into making sure the Salesforce record behind each document holds the right fields, in the right structure, before a single template is built.
Both. Lumin's Salesforce application is published as generating a document from a record, sending it for signature and tracking it back to that record, with templates whose variables are populated from Salesforce data. Because the product has been extended over time, we verify the current capability set in your own org during discovery rather than relying on a feature list — and we confirm what the app does natively before proposing any custom development around it.
It is driven by three things: how many distinct templates you need, how clean the Salesforce data behind them is, and how many approval or signing variations exist. A single document type on a well-structured object is a short engagement. A multi-entity, multi-region template set with conditional clauses and legal review cycles is a programme. We scope it from your document inventory in discovery and give you a phased plan rather than a single date.
If the requirement can be expressed in fields, templates, Salesforce Flow and permissions, it is configuration. The moment it needs code to run, an external system to respond, or a screen the platform does not provide, it is development — typically Apex, a Lightning Web Component, or Lumin Sign API and webhook work. We put that split in writing before the estimate, because it is where document project budgets usually go wrong.
We implement Lumin; we do not claim a formal Lumin partner credential. Twopir Consulting is a Salesforce Partner and a HubSpot Partner, and our work on Lumin is delivered as Salesforce consulting — architecture, configuration, integration and development around the application. We would rather be precise about that than imply a reseller relationship we do not hold.
Not automatically. Switching document platforms means rebuilding templates, retraining users and migrating history, so it only pays back when there is a concrete reason — cost per user, a licensing model that penalises volume, or a capability gap you keep working around. We assess your current setup against what you need and will tell you to stay where you are when that is the right answer. We also implement Conga Composer, Nintex DocGen, S-Docs and DocuSign, so the recommendation is not tied to one product.
Four controls, applied together: a field audit that maps every merge point to a real Salesforce field; formula or roll-up fields for anything derived rather than entered; validation rules so a document cannot be generated from an incomplete record; and template testing against live records including the awkward cases — missing values, multiple signers, unusual entities. Accuracy is an architecture outcome, not a proofreading step.
Next Step
Bring us the document that is slowing everything down
Come to the first call with one document and the record it should be built from. We will tell you what Lumin can do with it as configuration, what would need development, and what needs fixing in Salesforce first.
Discuss your Lumin requirements with a team that builds the Salesforce underneath
