DocForge Guide: Build and Automate Professional PDFs

Producing one polished letter or certificate is usually manageable. Producing 300 versions of it is where the real problems begin. Names arrive in the wrong column, dates use mixed formats, a required amount is blank, two recipients resolve to the same filename, and a last-minute layout edit makes it impossible to prove which design generated which file.

DocForge is Motifuse's document-generation studio for that work. You design a reusable PDF template, define the data fields it expects, connect spreadsheet or JSON records, validate every row, and generate one personalized document per valid record. Small batches can run entirely in the browser without an account or an upload. Signed-in workspaces can save templates, publish immutable versions, and—when their plan allows it—send larger jobs to a private cloud worker with tracked progress, retryable failures, ZIP archives, and time-limited downloads.

This guide explains the product that is actually implemented: its visual editor, starter library, field model, import and mapping workflow, validation, local and cloud generation, version history, team controls, quotas, security boundaries, and current deployment limits. It also identifies advanced capabilities that exist in the code but are not enabled in the audited production configuration, so you can distinguish today's product from its guarded rollout paths.

What DocForge is

DocForge is a template-based PDF production workspace. Its basic unit is not a blank word-processing page; it is a template plus structured data. The template controls layout and formatting. Each data row supplies values such as a candidate's name, an invoice number, a course title, a due amount, or a QR payload. The renderer resolves those values into a separate output document with a safe, predictable filename.

The product has two working modes:

• Local browser processing generates up to 25 PDFs in the current browser tab. It is free, needs no account, does not upload the source rows or generated files, and does not consume cloud credits.
• Secure cloud batches are available to cloud-capable workspaces. The source is uploaded to private storage, a background worker processes a pinned template version, every row receives a durable result, and outputs expire according to the workspace plan.

Both modes use the same PDF layout model and rendering engine. That parity matters: a preview in the editor is intended to represent what the cloud worker will produce, rather than being an approximate HTML mock-up of a different server renderer.

DocForge is not a general-purpose word processor, an electronic-signature service, or permanent document storage. It is a production system for repeatable, data-driven documents whose layout has been designed and reviewed in advance.

The problem it solves

Mail merge is a useful idea, but ordinary mail-merge workflows tend to break down around production controls. They often depend on one person's desktop application, accept malformed rows without a useful preflight report, overwrite previous output, and leave no reliable connection between a finished file and the exact template revision that created it.

DocForge separates the workflow into reviewable stages:

1. 1The design is saved as a template with typed fields.
2. 2A published template becomes an immutable version.
3. 3Source columns are mapped to the template fields.
4. 4Rows are validated before generation.
5. 5Valid rows generate while invalid rows remain visible with specific reasons.
6. 6Cloud jobs retain per-row status, hashes, lifecycle events, and a manifest.
7. 7Failed rows can be retried without regenerating successful rows or charging for them twice.

That structure is useful whenever correctness, repeatability, and privacy matter as much as visual output.

Who DocForge is designed for

DocForge fits teams that repeatedly turn structured records into consistent PDFs:

• Human resources and operations teams can prepare offer letters, appointment letters, experience certificates, notices, and other standardized employee documents.
• Freelancers, agencies, and consultants can generate invoices, client summaries, certificates, acknowledgements, and branded deliverables from a spreadsheet.
• Training providers and educators can produce course certificates, admit cards, event badges, and participant documents with names, dates, grades, and QR codes.
• Finance and administrative teams can create payment reminders, receipts, account notices, and other controlled correspondence. Financial or legal outputs still require qualified review.
• Nonprofits and community organizations can issue donation receipts or event documents from a verified register.
• Developers and platform teams can prepare integrations around versioned templates, scoped credentials, webhooks, and workflows when those services are enabled for their deployment.
• Larger workspaces can use approval queues, audit search, role assignments, and usage budgets where the Business governance entitlement is active.

It is less suitable for free-form collaborative writing, contracts that need negotiation and redlining, live spreadsheet calculations, or documents whose layout changes completely for every recipient.

Core features at a glance

The starter template library

The DocForge template gallery currently contains ten starters:

• Employee offer letter
• Appointment letter
• Experience certificate
• Course completion certificate
• Student admit card
• Event badge with QR code
• Freelancer invoice
• Payment reminder notice
• Donation receipt
• Rent revision letter

These are not decorative thumbnails. Each starter includes a real one-page PDF layout, defined fields, sample values, and an output filename pattern. For example, the offer-letter starter uses candidate and employment fields, while the invoice starter includes an item table, totals, tax information, and payment instructions.

Choose a starter when its document structure is close to your goal. Choose New template when the design is genuinely different. Choose Upload a base PDF when you already have approved letterhead, a certificate background, or a form and only need to place dynamic content over it.

Designing a template

Open the studio and select From starter or New template. The PDF editor is divided into Insert, Layers, Pages, and Fields panels, a central canvas, an Inspector, and an optional Preview.

Page setup and layout limits

Templates support A4, Letter, and Legal page sizes in portrait or landscape orientation. A layout can contain up to 20 pages, with up to 150 elements on each page. Margins, page order, orientation, backgrounds, headers and footers in enabled configurations, and watermark settings are stored with the template rather than inferred at render time.

The editor works in PDF points from end to end, which avoids repeated unit conversion between the browser preview and final output. Elements can be positioned, resized, layered, duplicated, aligned, and inspected. Keep layouts comfortably inside the page bounds; a design that only fits by a fraction of a point is vulnerable to overflow when real values are longer than the sample.

Elements you can place

The implemented PDF layout model supports:

• Static or token-bearing text
• Static images
• Dynamic images and signature assets on eligible plans
• Lines and rectangles
• Static tables
• Page numbers and generated dates
• QR codes on every plan
• Code 128, Code 39, EAN-13, and UPC-A barcodes on eligible plans
• Draft, Test, Confidential, and custom watermark modes, subject to plan rules

Headers, footers, repeating tables, and overflow addenda have supporting code and strict safety limits, but data-driven repeating blocks are not enabled in the audited deployment. Use the controls that the editor exposes rather than assuming every schema construct is available.

Fields and placeholders

The Fields panel defines the contract between the template and its data. A field has a label, a lowercase key, a type, an optional required flag, a default value, a sample value, and—where relevant—a display format. Field keys start with a letter, contain lowercase letters, numbers, or underscores, and are limited to 60 characters.

Insert a field into text with a placeholder such as {{employee_name}} or {{invoice_total}}. At generation time, DocForge replaces that token with the mapped row value. If the source is empty, it uses the field's default value when one exists; an empty required field becomes a validation failure.

Available field types include text, number, date, email, image, signature, and list/array definitions. Number fields can set decimals, grouping, prefixes, and suffixes. Date fields use explicit patterns. Image and signature values are references to assets already uploaded and verified in the workspace—not arbitrary web addresses—so a document row cannot make the renderer fetch an unknown URL.

Images, fonts, and base PDFs

Standard template images accept PNG and JPEG files and are content-validated before use. General images are limited to 10 MB, signatures to 2 MB, custom fonts to 8 MB, and base PDFs to 20 MB. Images with extreme dimensions or suspicious structure are rejected. Password-protected PDFs, PDFs containing scripts or embedded active content, and unsupported font structures are also rejected.

Base PDFs may contain up to 50 pages at upload validation, while an editable DocForge layout is capped at 20 pages. If a source PDF is longer, split it to the pages you actually need before importing it.

DocForge includes Helvetica, Times, Courier, Noto Sans, and Noto Devanagari families. The Noto fonts provide embedded Unicode coverage for text such as the rupee symbol and Devanagari. Pro and higher plans can use managed custom fonts, but the editor requires an explicit confirmation that you are licensed to embed each font.

Publishing and version history

Cloud generation uses published versions, not a moving draft. When you select Publish version, DocForge validates the layout, checks its fields and assets, lints likely problems, records the render-engine version and required assets, and creates an immutable version record. Concurrent publishing is rejected rather than creating two versions with the same number.

The Version history dialog can preview a published version and verify that its stored layout still matches its published hash. Paid plans can compare versions and restore an earlier one into the draft. A restore never rewrites history: it creates a new draft revision, and previously generated documents continue to reference the version that produced them.

This is a practical control, not just a technical one. If a customer asks why two batches differ, you can compare the versions instead of relying on someone's memory of the editor.

Cloud-capable plans also support saved template tests. A test stores a sample row and expected warning/page results, then runs it against the current draft with a fixed timestamp. Use tests for important templates before republishing after a layout or field change.

Importing data

Select Generate on a template to open the four-step wizard: Data, Mapping, Validation, and Generate.

Supported inputs

The Data step supports:

• CSV and TSV files
• Unencrypted XLSX workbooks, including sheet selection
• JSON arrays or common record wrappers
• Cells pasted from Excel or Google Sheets
• A manually entered single record

The browser importer accepts up to 10,000 rows, 120 columns, and 20,000 characters per cell. CSV input is capped at 50 MB, JSON at 25 MB, and pasted text at two million characters. When an input crosses row, column, or cell limits, DocForge shows what would be excluded or clipped and asks for confirmation rather than silently discarding data.

Nested JSON is a Pro-level capability. Nested objects are flattened into dotted column names, while arrays are represented as bounded JSON cells for compatible list fields. The importer limits nesting depth, object width, array length, total nodes, and unsafe property names.

Preparing a reliable source file

Use one header row, one record per output document, and unique column names. Keep identifiers such as invoice numbers as text when leading zeros matter. Store dates consistently, and do not rely on cell colors, hidden columns, formulas, or merged cells as business logic—the importer reads values, not the visual meaning of a workbook.

For tables or item lists, prepare a valid JSON array in the mapped cell and confirm that its item keys match the template's list definition. Because dynamic repeating tables are currently guarded, verify that the editor exposes the required list control before planning a production workflow around it.

Mapping source columns to fields

The Mapping step compares normalized column names with template keys and suggests exact matches. You review every required field and choose the source column that should supply it. A completeness indicator blocks the next step while a required mapping is missing.

Eligible workspaces can save mappings for reuse. Saved mappings carry a schema fingerprint so DocForge can detect drift when a spreadsheet's columns change. Rule-based transforms and shared mapping capabilities exist behind product controls; they should be treated as unavailable unless the current workspace interface offers them.

Common mapping mistakes include connecting a display label instead of the stable field key, mapping currency text into an unformatted number field, and using a person's name as a supposedly unique output filename. Resolve those issues before generation, not after reviewing hundreds of files.

Validation before generation

The Validation step evaluates each mapped record against the template. The summary separates Total, Valid, Warnings, and Failed rows. You can filter results, inspect field-level messages, preview a row, exclude selected records, and export validation-report.csv.

Checks include required values, number and date parsing, email validity, array structure, missing assets, unresolved tokens, layout constraints, rendered-page budgets, and output filename problems. A warning may still generate; a failed row is skipped.

Valid rows do not need to wait for bad rows to be corrected. That partial-success model is useful for operational work: generate the 198 clean records, fix the two failures, and retry only what remains.

Generating locally in the browser

Choose Local browser processing in the Generate step when the template is PDF and the batch contains no more than 25 included valid rows. Generation runs in a Web Worker so the interface remains responsive.

Local mode has important properties:

• Source records, template data, and output PDFs stay on the current device.
• No server storage is created.
• No cloud credits are held or finalized.
• One document downloads directly; a multi-document batch is assembled into a local ZIP.
• You can cancel the run, and temporary memory is released after the result is downloaded or discarded.

Local templates are stored in the browser and are limited to three. Browser storage is convenient, not a backup. Create a workspace if you need durable cloud-saved templates and cross-device continuity.

Generating in the cloud

Cloud generation requires a signed-in workspace, a cloud-capable plan, a cloud-saved template, and a published version. The Generate review shows how many documents will consume credit and how many remain available in the current billing period.

When you queue a job, DocForge uploads a bounded canonical source, reserves the expected quota, and creates an idempotent queue record. A private worker claims the job with a lease, verifies the pinned template assets, renders each valid row, packages the archive, and settles usage from durable results.

Job states include Queued, Processing, Packaging, Completed, Completed with errors, Failed, Cancelled, and Expired. The Cloud Jobs view shows totals, generated and failed counts, row-level status, retention time, downloads, and lifecycle details.

Only successfully generated documents become finalized usage. A terminal failure releases the unused hold. Selecting Retry failed creates a new processing pass for failed rows only; successful rows are neither regenerated nor billed twice. Cancellation is cooperative, so a worker finishes or safely fences the current operation before another attempt can own it.

Downloads, filenames, and output history

Output filenames come from the template's pattern and may include field tokens plus {{row_number}}. Filenames are normalized for common operating systems, control characters and reserved path characters are removed, and the stem is capped at 120 characters. Use an identifier in the pattern—such as invoice-{{invoice_number}}—instead of a name alone.

Completed cloud jobs offer:

• A ZIP archive for the batch
• Individual row downloads
• A generated-document library searchable by filename prefix
• Metadata CSV export for the document library
• A manifest and integrity verification for supported jobs
• Early deletion through Delete outputs now

Download links are short-lived. The server currently issues five-minute signed links, but the underlying file remains available until its retention deadline unless you delete it early. If a link expires while the output is still retained, request a fresh link from the job. After retention ends, regeneration or a new job is required.

Cloud output is PDF in the audited deployment. HTML and DOCX engines are present behind strict deployment flags, and PDF conversion pools for those formats are separately guarded. Do not promise those formats to recipients unless the template editor and session explicitly list them as enabled.

Collaboration and governance

A workspace can share DocForge resources with customer-owner, customer-admin, and customer-member roles. Owners and administrators can manage templates and jobs; members have a read-only baseline. The Business governance layer adds named, additive roles such as template editor, publisher, workflow operator, approver, delivery manager, auditor, and billing administrator. Grants can be scoped to a workspace or a specific resource and can expire.

Governance features include:

• Approval policies and an Approvals queue
• Searchable audit history
• Background audit exports with integrity hashes and 24-hour expiry
• Fine-grained role assignments
• Usage budgets and alerts

The workspace owner always retains recovery authority, and a non-owner grant cannot create owner-level team or billing power. Governance actions and privileged recovery operations require an audit reason.

The product also implements saved destinations, reusable workflows, lifecycle events, and document regeneration for eligible plans. Their visibility follows the owner workspace's effective plan and live service configuration.

Developer features and current API status

The Developers area includes scoped API-key management, a request playground, downloadable OpenAPI and Postman material, webhook endpoint management, delivery history, replay controls, and a request log. Keys are separated into test and live modes, shown only once when created, stored as one-way hashes, limited by scopes, and revocable.

However, implementation does not equal current availability. DocForge's API and webhook delivery have operator kill switches and a production allowlist. In the deployment audited for this article, both the public API and webhooks are disabled. Treat the developer surface as a controlled beta, not a generally available contract. The in-product status and support guidance are the current source of truth.

Email document delivery is similarly guarded. The workflow supports transactional attachment or short-lived-link delivery, per-day plan caps, suppression and provider feedback, test sends, and failure cutoffs. The interface only exposes it when a verified provider is operational. It is not enabled in the audited deployment, and it is not a bulk-marketing feature.

Security, privacy, and data handling

DocForge's privacy behavior depends on the processing mode.

Local mode

Local generation reads the template and rows in the browser, renders PDFs in a worker, and builds downloads on the device. There is no DocForge server upload, cloud queue record, or server retention window. Your operating system, browser extensions, and device security still matter, so local processing should not be confused with encryption of an unsafe endpoint.

Cloud mode

Cloud uploads use short-lived, signed upload authorization and private object storage. Stored objects are encrypted at rest, access is scoped by workspace, and application routes verify both resource ownership and the caller's role. Download links are signed and short-lived. Cloud logs are designed to contain job identifiers, counts, timings, and safe error codes rather than source rows, filenames, recipient addresses, or rendered content.

Template assets and source files are checked by content rather than trusting their extension. PDFs with active content or encryption are refused. Images are normalized and bounded. Fonts are structurally validated. Dynamic row images resolve only from verified workspace assets, which prevents a source row from turning the renderer into a general URL fetcher.

Published template versions include hashes and pinned asset information. Cloud job writes are lease-fenced so a stale worker cannot overwrite a newer attempt. Output deletion produces an auditable receipt, and retention cleanup has an infrastructure backstop.

Review the platform Privacy Policy, Terms of Service, and security information before processing regulated, confidential, or third-party data. You are responsible for having a lawful basis and permission to use the source records, logos, signatures, fonts, and document text.

Free and paid access

Plan limits are enforced from the live plan catalog, so the DocForge pricing page is the best source for prices and current sale availability. The default entitlement matrix is:

Every plan keeps the local 25-document mode. Cloud plans also enforce page, storage, asset, delivery-attempt, API-request, and retained-job meters. The Usage & Plan view is the authoritative place to see the selected workspace's current limits, used amount, outstanding holds, and available balance.

DocForge may run a temporary promotional-access program through a server switch. When that switch is active, signed-in workspaces receive bounded Business-like access without checkout; it is not unlimited and does not automatically cancel an existing subscription. The switch was not active in the environment audited for this article.

Practical use cases

Offer letters for a hiring round

Start with the Employee offer letter template, replace the brand and terms with approved content, and define required fields for candidate name, role, compensation, joining date, and location. Import the hiring spreadsheet, map columns, export the validation report for HR review, and generate locally for a handful of offers or use a version-pinned cloud batch for a larger intake.

Certificates and admit cards

Use the course certificate or admit-card starter. Include a stable learner or roll identifier in the filename, not just the person's name. QR fields are available on every plan, so the code can carry an approved verification URL or check-in value. DocForge creates the code; your organization remains responsible for the verification service and for ensuring the certificate has the required authority.

Invoices and payment reminders

Define invoice numbers as text, amounts as number fields with an explicit format, and dates with one display pattern. Preview the longest customer name and largest amount before publishing. For finance-related documents, reconcile totals with the source system and review tax or legal text independently; DocForge formats supplied values but is not accounting software.

Event badges

The event-badge starter places two badges on an A4 page and includes a QR field. Validate names and roles, keep payloads short, and print a physical sample before the event. Screen rendering cannot guarantee how a particular printer, stock, cut line, or scanner will behave.

Donation receipts and administrative notices

The donation-receipt and rent-revision starters show how to standardize repetitive correspondence while retaining per-recipient values. Make required identifiers and dates explicit, publish an approved version, then archive the source register according to your own records policy after the DocForge outputs expire.

Custom operational documents

When an approved form already exists, upload it as a base PDF and position text, dates, images, or QR values on top. If the workflow needs a specialized application rather than a reusable template, Motifuse also accepts private tool requests.

A reliable end-to-end workflow

1. 1Open DocForge and choose From starter, New template, or Upload a base PDF.
2. 2Set the page size and orientation, then place and align the static design elements.
3. 3Open Fields, create meaningful typed keys, mark genuinely required fields, and add realistic samples.
4. 4Insert placeholders into text and configure the output filename pattern.
5. 5Use Preview with long names, empty optional values, large amounts, and multi-line content.
6. 6Save the draft. For cloud use, sign in through the workspace, upload verified assets, resolve lint warnings, and select Publish version.
7. 7Select Generate, add data in the Data step, and confirm sheet or import warnings.
8. 8Review Mapping until every required field is connected.
9. 9Inspect Validation, preview representative rows, export the validation report, and exclude or fix failed records.
10. 10In Generate, choose local or cloud processing, confirm the document count and retention behavior, and start the batch.
11. 11Download the direct PDF or local ZIP. For cloud work, open Cloud Jobs, review row outcomes, download retained files, and use Retry failed only after correcting the cause.
12. 12Delete sensitive outputs early when they are no longer needed, and keep any required business record in your approved system of record.

Input and formatting guidelines

These are hard product ceilings, not performance targets. A 20-page template with many embedded images is much heavier than a one-page letter. Test representative production rows and assets before scheduling the maximum batch your plan allows.

Troubleshooting

When a server failure occurs, the API returns a support reference instead of exposing internal stack details. Keep that reference and the opaque job identifier when contacting support; do not send the entire source file unless support provides an approved secure channel.

Best practices for reliable documents

• Design with extremes, not averages. Preview the longest name, widest number, missing optional image, and largest list you realistically expect.
• Use stable identifiers in filenames. Combine a human-readable label with an invoice, employee, learner, or receipt ID.
• Keep field keys stable. Change the label shown to users when wording evolves, but avoid renaming a key that existing mappings depend on.
• Make only true requirements required. Overusing required fields turns harmless blanks into failed batches; underusing them creates incomplete documents.
• Publish deliberately. Treat a published version as an approved production artifact. Summarize the change, run saved tests where available, and keep approvals tied to the exact content reviewed.
• Validate before every batch. A mapping that worked last month can drift when an export changes its headers or date conventions.
• Use local mode for sensitive small batches. It avoids server transfer entirely. Use cloud mode when you need scale, durable job tracking, retries, shared history, or controlled downloads.
• Keep media modest. Resize logos and photos before upload. Huge images increase memory, render time, archive size, and the risk of hitting plan meters without improving print quality.
• Confirm font rights. A font being downloadable does not necessarily grant document-embedding rights.
• Print a physical sample. Check QR/barcode scanning, margins, duplex behavior, paper size, and external PDF viewers before a production print run.
• Delete early and archive intentionally. DocForge is temporary processing storage. Move required records to your approved document system and remove unneeded cloud outputs.
• Protect credentials. Save API keys only in a secret manager, use the narrowest scopes, start in test mode, rotate them without copying into spreadsheets or source control, and remember that the API is currently controlled beta functionality.

Important limitations

• PDF is the only enabled output format in the audited deployment. HTML and DOCX code paths are guarded and should be considered unavailable unless the product reports otherwise.
• Dynamic repeating blocks, rule transforms, remote asset import, transactional email delivery, and the public API/webhooks are not enabled in the audited configuration.
• Local batches are capped at 25 documents and depend on the memory and performance of the device and browser.
• Browser-local templates are convenient but are not a durable cross-device backup.
• Base PDFs cannot be password-protected and cannot contain scripts, actions, or embedded files.
• DocForge does not calculate invoice totals, decide legal wording, verify academic authority, sign contracts, or certify that source data is correct.
• PDF appearance can vary slightly across viewers and printers. Embedded supported fonts reduce differences but do not eliminate device, paper, or printer effects.
• Cloud outputs expire; the product is not a permanent records repository.
• Business self-serve sale is readiness-gated, Starter is a legacy tier, and Enterprise is provisioned rather than purchased through ordinary checkout.
• The interface and live session response outrank this article when an operator changes an entitlement or feature switch.

Frequently asked questions

The bottom line

DocForge turns a fragile mail-merge task into a reviewable production workflow: design once, define a clear data contract, validate before generation, pin cloud work to an immutable version, and keep successes separate from failures. The free local mode is useful on its own for small, sensitive batches, while cloud plans add scale, history, retries, retention controls, and—where enabled—team governance and automation.

The best way to evaluate it is with a real but non-sensitive sample. Open DocForge, choose one of the starter templates, replace the sample values with edge cases from your workflow, and generate a small local batch. If the preview, validation report, and filenames all make sense, you have a sound foundation for a larger production run.