Feature · CRM Document Automation

A proposal, assembled from the record, ready to sign.

Pick a template, point at a deal, and the proposal fills itself from record data. Pricing from the Products module, contact names from the account, legal clauses from the clause library. Route for approval, send through DocuSign or PandaDoc, log the signed PDF on the record. Document assembly stops being a hour of copy-paste.

Start free trial See pricing
What assembly looks like

Template plus record equals finished document.

Document assembly on Strkr runs on a template-plus-merge model. The template holds the layout, the boilerplate, and the merge fields that pull from the record. The rep picks the template and the source record (opportunity, account, contract); the system fills the merge fields and renders the finished document in under three seconds for a typical proposal.

Template library

Shared templates per tenant.

The template library stores every document template the tenant uses: proposals, contracts, SOWs, invoices, NDAs, order forms, delivery acknowledgments, renewal letters. Templates carry tenant-level versioning so legal reviews a changed clause once and the new version propagates. Reps never work from a stale template; the gallery shows the current approved version.

Merge fields

Record data flows into placeholders.

Templates use double-brace placeholders: {{account.name}}, {{opportunity.amount}}, {{primary_contact.full_name}}, {{deal.renewal_date | format:date}}. The renderer resolves placeholders against the source record and any linked records up to three hops out. Formatting filters cover dates, currency, percent, lists. The syntax is readable without learning a template language.

Clause library

Legal-approved blocks ready to drop.

The clause library stores pre-approved legal blocks: data processing addendums, SLA terms, indemnification language, limitation of liability variants. Templates reference clauses by key; a legal review of a clause update propagates to every template referencing it. Reps never paste a stale clause; legal never audits a hundred documents to confirm current language.

Product tables

Line items render from the deal.

Proposals and invoices with product line items pull directly from the Opportunity Products or Invoice Items record. The template renders a table with product name, quantity, unit price, discount, extended price, computed subtotal, tax, total. Changes on the opportunity side regenerate the document without a rep editing the table manually.

Conditional sections

Show or hide blocks per record state.

Templates support conditional sections that render based on record values. A contract template might include the data processing addendum only if the account country is in the EU, or the enterprise SLA block only if the ARR exceeds $100K. The condition is a small expression; the rendered output never carries irrelevant boilerplate.

Branded output

Tenant logo, colors, fonts enforced.

Templates inherit the tenant brand kit: logo on the header, color palette on headings and tables, font family on body text, footer with company address and legal entity. Reps cannot override brand elements per document; the posture keeps outgoing material visually consistent. Updates to the brand kit propagate across templates on next render.

Approval routing

Policy-driven approvals before send.

Documents that touch pricing, contract terms, or legal exposure typically require internal approval before they reach the prospect. The Strkr approval engine routes approvals based on tenant-defined policy, not based on rep manual escalation. The policy sits as code in the admin console; the audit log captures every approval and decline.

Approval policy

Rules by document type, amount, discount.

The approval engine takes a policy expressed as a set of rules: a proposal with discount over 15 percent routes to the AE manager; over 25 percent routes to the VP; a custom MSA routes to legal regardless of amount. Rules compose; a document can require multiple parallel or sequential approvals. The policy editor lives on the admin surface with a diff view for changes.

Approver queue

Pending approvals in one list.

Approvers see pending documents in a queue on their home dashboard with record context, approval reason, and the policy clause that triggered the routing. Approving is one tap; declining requires a reason that writes back to the submitting rep. The queue shows SLA state so pending approvals that exceed the configured window surface as yellow or red.

Parallel approvals

Legal and finance both review.

Documents that require both legal and finance approval route in parallel; both approvers see the queue entry; the document moves forward when both approve. Serial approvals are the alternative for policies where legal must review before finance. The routing shape is a policy decision; the engine supports both shapes without workaround.

Approval delegation

Out-of-office auto-forwards.

An approver on PTO can delegate their queue to a designated backup for a date range. The engine routes new submissions during the window to the backup; the original approver sees the submissions on return. Delegations respect the policy posture; a VP delegation to a director still enforces the VP-level clause match.

Approval audit

Every decision writes to the log.

Each approval event (submission, approval, decline, delegation, override) writes a tamper-evident audit log entry with timestamp, approver, document version, policy clause triggered. Compliance teams review the log without reconstructing from email threads. SOC 2 Type II (in progress through 2026-Q4) controls read this ledger for approval audit evidence.

Policy override

Exceptions require elevated permission.

An approver with the override permission can bypass policy for exceptional cases (CEO override for a strategic account). The override requires a written reason, writes to the audit log, and surfaces on the quarterly compliance review. The permission is scoped tightly; the pattern exists for edge cases, not routine use.

Signature

DocuSign and PandaDoc integrated routing.

Strkr does not run a native e-signature service. For legally binding signatures, the shipped integrations with DocuSign and PandaDoc handle the routing, the signer flow, the audit chain, and the storage. The integration layer puts the signed PDF back on the Strkr record automatically.

DocuSign send

Prepare envelope from the record.

A rep hitting Send for signature on a finished document creates a DocuSign envelope with signer fields pre-placed based on template markers. Signers map from the record (primary contact, account billing contact, Strkr signer identity). The envelope sends through the DocuSign API; the rep never leaves Strkr to prepare it.

PandaDoc flow

Native embedded signing option.

The PandaDoc integration supports embedded signing where the signer completes the document inside a Strkr-hosted iframe. The flow suits inbound motions where the prospect is already on the Strkr portal (configure, price, approve) and should not be bounced to an external vendor domain. The posture is a tenant choice per template.

Status sync

Signed, declined, voided states flow back.

The signature vendor pushes status updates via webhook: sent, viewed, signed, declined, voided, expired. Each state writes to the document record on Strkr and triggers the matching flow action. A signed envelope triggers the Closed Won automation; a declined envelope triggers a notification to the AE with the decline reason.

Signed PDF

Fully signed version lands on the record.

Once all signers complete, the fully-signed PDF (with embedded certificate of completion) pulls back to Strkr and attaches to the document record. The record carries both the pre-signature draft and the final signed version. Compliance reviews find the fully-signed document on the record without hopping to the signature vendor.

Audit chain

Certificate of completion preserved.

DocuSign and PandaDoc both emit certificates of completion with signer identity verification, IP address, timestamp per field, and chain of custody. The certificates attach to the Strkr document record for the lifetime of the record. Legal challenges to a signed agreement find the full chain without a vendor API round-trip.

Multi-signer coordination

Routing order and parallel signatures.

Templates with multiple signers (buyer, buyer legal, seller AE, seller legal) support routing order (sequential signing with each signer notified after the prior completes) or parallel order (all signers notified at once). The pattern suits different deal shapes; a strategic enterprise deal usually runs sequential while a quick inbound SMB deal runs parallel.

Record automation

Documents trigger next steps automatically.

A sent proposal is also a record state change. Strkr Flow treats document events as first-class triggers so sending, viewing, and signing drive the next motion without rep tapping. The pattern turns document automation into pipeline automation.

Document sent

Enroll in the proposal-review sequence.

A proposal-sent event triggers enrollment in a review sequence: 48 hours later a check-in email, 5 days later a nudge SMS, 10 days later an escalation task on the AE. The sequence halts on view-and-reply or on signature. The pattern replaces the I will follow up Thursday rep intention with a scheduled motion.

Document viewed

Prospect opens, AE knows.

A document-viewed event (first open, each subsequent open) notifies the AE on Slack with the viewer identity and the page viewed. Teams see signal that a procurement team is reviewing the contract on page 7 for twelve minutes; the AE calls at the right moment with the right context.

Document signed

Closed Won fan-out fires.

A fully-signed document triggers the deal transition to Closed Won. The transition fans out: onboarding project creation, success manager notification, invoice generation, welcome kit send, usage-dashboard provisioning. One signature event drives seven follow-on actions through the standard flow pattern.

Document declined

Loss analysis routing.

A declined document triggers loss analysis: the AE sees a loss-reason-capture task, the manager sees a competitive-loss review widget, Strkr AI drafts a loss-reason summary from the signer comment. Teams learn from losses systematically rather than through sporadic post-mortems.

Document expired

Expired envelope reopens the deal.

An expired envelope (sent but not acted on within the configured window) triggers a re-engagement task on the AE with the prospect inactivity timeline. The pattern catches the we sent it and never heard back failure mode that otherwise causes deals to quietly rot in Proposal Sent for a quarter.

Document voided

Reopening a signed document trail.

When a legal change requires voiding a signed document (replacement amendment, correction), the void writes a complete audit entry with reason. The replacement document references the voided one; both stay on the record. Compliance reviews see the full chain of amendments without hunting through email.

Compliance posture

HIPAA, SOC 2, data residency, retention.

Documents often carry the most sensitive data in the record: pricing commitments, personal data, protected health information. The Strkr document surface respects the broader compliance posture: HIPAA with BAA, SOC 2 Type II in progress through 2026-Q4, tenant-controlled retention, regional data residency.

HIPAA posture

BAA covers document generation.

Teams in healthcare run document generation under the standard Strkr BAA. Protected health information rendered into a document stays inside the tenant-encrypted storage; the signature vendor chain (DocuSign BAA or PandaDoc BAA where available) extends the posture through signing. Audit logs capture every PHI document access with the matching HIPAA fields.

SOC 2 Type II

Audit controls through 2026-Q4.

Document generation lives inside the SOC 2 Type II audit scope (in progress through 2026-Q4). Template change management, approver-role access reviews, at-rest encryption of generated artifacts, and incident response procedures all feed the audit evidence pool. Once the audit lands, the attestation letter is downloadable through the Strkr trust portal.

Data residency

EU, UK, CA, AU footprints respected.

Documents on an EU tenant stay in the EU region at rest; the signature vendor runs in the matching region (DocuSign EU, PandaDoc EU). No cross-region hops in the normal path. The posture matters for GDPR data-flow mapping and for teams in regulated regions with strict residency requirements.

Retention policy

Tenant-set from 1 year to 7 years.

Document retention follows a tenant-set schedule per document type: proposals default to 2 years, contracts to 7 years, NDAs to the signed-NDA policy. Expired documents purge from active storage with an audit entry preserved. Legal holds pause retention for specific records; the hold writes to the audit log and shows on the record detail.

Encryption at rest

Per-tenant KMS keys.

Documents at rest encrypt with per-tenant AWS KMS keys. Key rotation runs on the tenant-controlled cadence; rotations do not require document re-encryption (the key hierarchy design uses key encryption keys). Access to decrypt a document requires the standard permission matrix plus KMS-level audit, which lands in CloudTrail for enterprise audit evidence.

Open integration

Documents export via the open API.

Document assembly, approval routing, and signature state publish through a documented REST surface (OpenAPI 3.1 under the Strkr trust center). Teams building against a specialized CLM or clause-management vendor connect through the open contract, backed by first-class client libraries in TypeScript, Golang, and Python. Nothing locks document data inside a proprietary silo; export and bidirectional sync both ship.

Send yourself a proposal from a demo tenant in 15 minutes.

Bring a sample pricing shape; we will build a proposal template on screen, trigger the approval route, send the DocuSign envelope, and show the signed PDF landing on the record.

Book a document demo Explore the workflow builder
Common questions

What buyers ask about this feature.

Does Strkr run its own e-signature service?

No. Strkr integrates with DocuSign and PandaDoc for legally binding signatures. The decision reflects that e-signature is a specialized compliance product with mature vendor coverage; building a native alternative would duplicate functionality without adding tenant value. Strkr handles document assembly, approval routing, signer coordination, and the status sync back to the record; the signature vendor handles the signing surface, the certificate of completion, and the long-term legal chain of custody.

Can we use a different e-signature vendor like Adobe Acrobat Sign or Dropbox Sign?

The core supported vendors are DocuSign and PandaDoc, which cover the plurality of mid-market and enterprise usage. Teams on Adobe Acrobat Sign or Dropbox Sign can integrate through the open document API; the integration shape is similar (envelope creation, status webhook, signed PDF retrieval). The lift for a new vendor adapter typically runs two to four weeks depending on the vendor API quality; shipped SDKs and OpenAPI 3.1 spec cover the integration contract.

What happens if the DocuSign envelope errors out during send?

Send errors (expired signer email, invalid envelope state, DocuSign rate limit) write to the dead-letter queue with the full envelope payload and the error. The admin dashboard shows failed sends; the fix is usually a one-click retry after resolving the underlying issue (email correction, rate-limit wait, tenant reconnect). The pattern avoids the common the proposal silently never sent failure mode that split-system setups suffer from.

How do we handle a document that needs legal red-lining before signature?

The Strkr document record supports attachments for red-line versions and comments. A legal red-line typically comes back from the counterparty as an edited Word file; the AE attaches the red-line to the record, creates a legal-review task, and the clause editor shows the delta. Once legal approves the changes, the AE regenerates the document from the updated template version and reissues the envelope. For teams running heavy red-lining, a contract lifecycle management tool like Ironclad or Agiloft integrates through the open API.

Can one template support multiple languages?

Yes. Templates carry language variants that render based on the record locale or an explicit template-choice field. A proposal template might ship in English, French, German, Japanese, Spanish; the renderer picks the variant matching the account billing-country locale. Legal clauses in the clause library carry matching language variants where applicable. The pattern avoids maintaining a separate template per language.

How does automation know when to generate a document?

Document generation integrates with Strkr Flow as a first-class action step. Common patterns: Opportunity moved to Proposal stage triggers proposal generation and send; Milestone marked Complete triggers invoice generation; Account tier upgraded triggers a renewal letter. The automation posture turns document creation from a manual rep task into a flow-driven motion; the rep reviews the draft but does not assemble it from scratch.

Related features

Pair this with...

CRM Automation Examples CRM Workflow CRM with Workflow Automation Automate Document Workflow Strkr AI Document Automation CRM Pipeline Stages

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing