Contracts & E-signature
By Conversa Labs
By Conversa Labs
Issuing companies, A1 certificate, templates, variables, auto-fill, internal/external signing, public page and validator.
Contracts & E-signature overview
Overview The Conversa Labs Contracts & E-signature module lets you create, send, sign and validate contracts without leaving the platform. You build documents from templates with variables, fill in the data automatically from information that already lives in your support workspace (contact, conversation, CRM deal, catalog and account), send the signing link through native channels (WhatsApp and email) and track the status in real time. The signing process is fully electronic and offers different legal levels — from a simple signature (consent with IP and device record) to a qualified one with an ICP-Brasil A1 digital certificate. Every contract produces an immutable audit trail, a final signed PDF and a public validation page so anyone can check the document's authenticity. Prerequisites - The Contracts module is optional and must be enabled for your account. If you can't find the Contracts area, talk to an administrator. - Your user needs permission to access and manage Contracts. - To issue contracts you must register at least one issuing company (the "contracted" party). For qualified signatures, that company needs an A1 digital certificate. - To send the signing link through channels, have a WhatsApp or email Inbox configured. Step by step 1. Open the Contracts area from the sidebar (commercial section, next to Payments). 2. Register your issuing company and, if you'll use qualified signatures, upload its A1 certificate. 3. Create a contract template in the editor or upload a ready-made model, using {{ }} variables wherever the content changes from one contract to another. 4. Generate a contract from the template: variables are filled in automatically with the contact/conversation/deal data; adjust anything missing. 5. Define the signers and the desired signature level. 6. Send the link through native channels. The contracted party can sign automatically; the other signers sign on the public page. 7. Track the status to completion and download the signed PDF. Share the validation page whenever you need to prove authenticity. Settings & options - Issuing companies: register as many as you need, each with its own details, branding and A1 certificate. - Templates and clauses: a reusable library of models and clauses. - Signature levels: simple, advanced (with OTP) and qualified (A1). - Module settings: document retention, time-stamping (TSA) and other adjustments. - Automation: contracts can be created/sent via Automations, Macros and the Flow Builder. Use cases - Close a deal in the CRM and send the contract for signature in the same conversation. - Issue service agreements, proposals and membership terms with a standardized model. - Collect a signature over WhatsApp with OTP for stronger legal assurance. - Generate a charge in the Payments module right after the contract is signed. Tips, limits & best practices - Standardize your contracts as templates to gain speed and reduce mistakes. - Choose the signature level based on the document's risk — the higher the value, the stronger the recommended signature. - For full legal validity of qualified signatures, keep the A1 certificate valid and, where applicable, configure an accredited time-stamp (TSA). - Always double-check the auto-filled data before sending for signature. Troubleshooting - I don't see the Contracts module: it may not be enabled for the account or your role — talk to an administrator. - I can't issue a qualified contract: make sure the issuing company has a valid, in-date A1 certificate. - The signer didn't get the link: confirm the channel (WhatsApp/email) and the signer's contact details. See also - Issuing companies and the A1 digital certificate - Templates, variables and auto-fill - Internal and external signing - Public contract page and validator
Issuing companies and the A1 digital certificate
Overview The issuing company is the "contracted" party of your contracts — the one that issues and, where applicable, signs the document automatically on your side. You can register as many issuing companies as you need (for example, one per brand, branch or tax ID), each with its own details, branding and digital certificate. To use a qualified signature (ICP-Brasil), the issuing company needs an A1 digital certificate — a password-protected .pfx/.p12 file. That certificate is uploaded to the platform and used to sign contracts with stronger legal validity. Prerequisites - Contracts module enabled for the account and a user with permission to administer Contracts. - The company's registration details (legal name, tax ID, address, contact). - For qualified signatures: a valid A1 certificate in .pfx/.p12 format and its password. - The A3 certificate (hardware token/card) is not supported in this version — only the A1, which is a file. Step by step 1. In the Contracts area, open the issuing companies section. 2. Create a new issuing company and fill in its registration details. 3. Add the branding (logo and colors), which will appear on the contract and the public pages. 4. To enable qualified signatures, upload the A1 certificate (.pfx/.p12) and enter its password. 5. The platform validates the certificate: if the password is wrong or the file is invalid, the upload is rejected with an error message. 6. When valid, the certificate holder and the expiry date are shown. 7. Save. The issuing company is now ready to be used when generating contracts. Settings & options - Multiple issuers: keep as many issuing companies as your business requires. - Branding per company: each one's own logo and colors, reflected in the document and the validator. - Certificate status: the platform shows holder, file and expiry; replace the file when you renew it. - Time-stamp (TSA): in the module settings you can point to an accredited time-stamp server to strengthen validity (TSA authentication is kept in the environment, not on screen). Use cases - A company with multiple brands/tax IDs issuing contracts under different identities. - An operation that needs stronger legal validity via an A1 certificate. - Standardizing the look of contracts (logo and colors) per issuing company. Tips, limits & best practices - Keep the A1 certificate always valid — an expired certificate blocks new qualified signatures. - Treat the certificate password as a secret: it is required in order to sign. - The certificate is sensitive data — only users with admin permission should manage it. - For full validity in Brazil, combine the A1 with an accredited time-stamp (TSA). Troubleshooting - The certificate upload was rejected: check that the password is correct and that the file is a valid, uncorrupted .pfx/.p12. - The expiry shows as expired: the certificate has expired; generate/renew a new A1 and upload it. - I can't sign in qualified mode: make sure the selected issuing company has a valid A1 loaded. - I need A3 (token/card): it is not supported in this version yet; use the A1 (file). See also - Contracts & E-signature overview - Templates, variables and auto-fill - Internal and external signing - Public contract page and validator
Templates, variables and auto-fill
Overview Templates are reusable models of your contracts. You create a template once, define the variable parts with {{ }} (for example, customer name, tax ID, amount, dates) and generate as many contracts from it as you like. When generating, the variables are filled in automatically with the data that already exists in your workspace — contact, conversation, CRM deal, catalog and account — leaving you to simply review and adjust anything missing. You can build the template in the platform's editor or upload a ready-made model. There is also a reusable clause library to standardize common passages across multiple templates. Prerequisites - Contracts module enabled and a user with permission to manage templates. - The contract content (base text) and the list of fields that change from one contract to another. - For auto-fill to work well, the source data (contact, deal, etc.) should be populated. Step by step 1. In the Contracts area, open Templates and create a new one. 2. Write the content in the editor or upload a ready-made model. 3. Wherever the text changes from one contract to another, insert a variable in the form {{ variable }}. 4. Reuse common passages from the clause library. 5. Save the template. 6. To issue, generate a contract from the template: the variables are filled in automatically with the source data (contact/conversation/deal/catalog/account). 7. Review the filled-in values, manually adjust anything missing and proceed to signing. Settings & options - Data source: variables can be filled from the contact, conversation, CRM deal, catalog and account data. - Manual entry: any variable can be edited by hand before sending. - Agentic generation: Maestro can help draft/fill the contract from the conversation context. - Clause library: standardize clauses and reuse them across multiple templates. - Model upload: import an already-formatted document and turn it into a template. Use cases - A standard service agreement with variable name, tax ID, scope and amount. - Proposals and membership terms that change only a few fields per customer. - Reuse of legal clauses (confidentiality, termination, jurisdiction) across different templates. Tips, limits & best practices - Give variables clear names so automatic and manual filling is obvious. - Check that each {{ variable }} has been replaced before sending — empty variables can leave gaps in the document. - Centralize common clauses in the library to keep consistency and ease updates. - Always review the generated contract: auto-fill speeds things up, but the check is your responsibility. Troubleshooting - A variable wasn't filled in: the source data may be empty (e.g., a contact with no tax ID). Populate the source or edit it manually. - The text came out with literal {{ }}: check the spelling of the variable in the template. - The uploaded model lost its formatting: adjust the formatting in the editor after the upload. See also - Contracts & E-signature overview - Issuing companies and the A1 digital certificate - Internal and external signing - Public contract page and validator
Internal and external signing
Overview A contract usually has two sides: the contracted party (your issuing company) and the external signers (the customer and other parties). In Conversa Labs: - Internal signing is the contracted party's auto-signature — performed server-side, using the issuing company's details (and, for qualified signing, its A1 certificate). - External signing is done by the signers through a secure public page, with no need to sign up or log in. You choose the signature's legal level based on the document's risk: simple (consent with IP and device record), advanced (with OTP by email/WhatsApp and a visual signature) or qualified (an ICP-Brasil A1 digital certificate, PAdES standard). Prerequisites - Contracts module enabled and a contract generated from a template. - A registered issuing company (for the auto-signature). For the qualified level, it needs a valid A1 certificate. - To send the link to external signers, a native channel (WhatsApp or email) and the signers' contact details. Step by step 1. On the contract, define the signers (the contracted party and the external signers). 2. Choose the signature level (simple, advanced or qualified). 3. Send for signature: each external signer receives, in their own conversation, a card with the contract summary, the signing link inside the message text and the PDF attached. On the channels that support it, the link also shows up as a button. When a signer only has an e-mail address, the invitation goes out by e-mail with the same link and the same PDF. 4. The contracted party signs automatically (server-side auto-signature). 5. Each external signer opens the public page, reviews the document and signs. 6. At the advanced level, the signer validates an OTP code and records a visual signature (drawn, typed or uploaded as an image). 7. Once all signatures are complete, the final signed PDF is generated and the status becomes completed. Settings & options - Signature levels: - Simple — consent with capture of IP, date/time and device. - Advanced — OTP by email/WhatsApp + visual signature (drawn, typed or uploaded). - Qualified — A1 digital certificate (ICP-Brasil), PAdES standard. - OTP delivery channel: set per signer. A signer configured for e-mail OTP gets the code at their registered address; one configured for WhatsApp OTP gets it in their own conversation. If the configured channel is unavailable the system tries the other one before giving up — and when neither exists it says so instead of treating the delivery as done. - Individual link: every signer has their own link, valid only for them. A signer never receives another party's link. - Auto-signature: the contracted party signs automatically with the issuing company. - Order and multiple signers: define who needs to sign. - Time-stamp (TSA): when configured, it strengthens the signature's legal validity. - Audit trail: each signature records IP, device, consent and timestamp (SHA-256). Use cases - A customer signs over WhatsApp with OTP in a few taps, installing nothing. - A higher-value contract requires a qualified signature with an A1 certificate. - The contracted party signs automatically and just waits for the counterparty. Tips, limits & best practices - Use the advanced (OTP) or qualified level for higher-value or higher-risk documents. - Make sure the signers' contact details are correct so the link is delivered. - For the qualified level, keep the A1 certificate valid and, if applicable, an accredited TSA configured. - Track the contract's status — it shows who has signed and what's still pending. Troubleshooting - The send was refused: when a signer has neither a phone number nor an e-mail address, the contract is not sent and the error names who has no destination. Complete the details and send again — the contract stays a draft until the send actually happens. - The signer didn't get the link: confirm the channel and contact details; resend if needed. - The OTP code doesn't arrive: check that signer's email/WhatsApp (the code goes to the channel configured on them, not to the contract's conversation) and resend. - The qualified auto-signature failed: make sure the issuing company has a valid, in-date A1 certificate. - The contract won't complete: check that all signers have signed. See also - Contracts & E-signature overview - Issuing companies and the A1 digital certificate - Templates, variables and auto-fill - Public contract page and validator
Public contract page and validator
Overview Every contract has a secure public page, accessible through a link, where external signers review the document and sign — with no need to sign up or log in. This page shows the contract content with the issuing company's branding and guides the signer through the signing flow (including OTP and the visual signature, when the level requires it). After it's signed, there is also a public validator: a verification page that lets anyone check the authenticity of the contract and the final signed PDF. The validator shows verification details in a masked way (without exposing sensitive data), backed by the immutable audit trail (SHA-256, IP, device, consent and timestamp). Prerequisites - A contract sent for signature (for the public signing page) or already signed (for the validator). - The matching link, delivered to the signer through native channels or shared for validation. - No login is required for the external signer or for whoever validates. Step by step 1. Send the contract for signature: the signer receives the public page link. 2. On the public page, the signer reviews the document and follows the signing flow. 3. Depending on the level, they confirm an OTP and record the visual signature. 4. Once the signatures are complete, the platform generates the final signed PDF with the manifest/certificate. 5. To prove authenticity, open (or share) the public validator page. 6. The validator confirms whether the document is authentic and shows the verification details in a masked form. Settings & options - Branding: the public page uses the issuing company's logo and colors. - Flow by level: simple, advanced (OTP + visual signature) or qualified (A1). - Final signed PDF: generated on completion, with the audit trail and manifest/certificate. - Masked validator: shows the verification without exposing sensitive data (privacy/LGPD). - Time-stamp (TSA): when configured, it appears in the verification to strengthen validity. Use cases - Send the customer a signing link that opens straight on their phone, with no install. - Provide a third party (bank, registry, auditor) with a contract validation link. - Prove the integrity of the signed PDF at any time, even after closing the deal. Tips, limits & best practices - Share the validator when you need to prove authenticity without sending sensitive data. - Advise the signer to open the public page in an up-to-date browser. - Keep the final signed PDF — it carries the audit trail and the verification manifest. - Remember the validator is masked by default to protect personal data. Troubleshooting - The public page link won't open: check that the link is complete and that the contract is still active (not canceled/expired). - The validator says the document was not found: check that the contract was completed and that the validation link is correct. - The PDF doesn't match the verification: the file may have been altered — always use the final signed PDF generated by the platform. - The signer can't sign: check the required level (e.g., OTP) and the contact details for sending the code. See also - Contracts & E-signature overview - Internal and external signing - Templates, variables and auto-fill - Issuing companies and the A1 digital certificate
Manage and track contracts
Overview The Contracts area gathers every document in your account into a list you can filter and where you follow each contract's lifecycle in real time. Each contract moves through well-defined states: - Draft — the contract was generated from a template and can still be edited. - Sent / in signature — the signing link was delivered and the document is awaiting the parties. - Partially signed — at least one signer has signed; others are still pending. - Completed — all signatures were collected and the final signed PDF was generated. - Voided — the contract was irreversibly cancelled after being sent. - Expired — the signing deadline passed without completion. - Rejected / cancelled — a signer declined or the contract was closed with no effect. From the list and the contract screen you run every management action (send, remind, void, duplicate, download, share links) and inspect the immutable audit trail. Prerequisites - The Contracts module must be enabled for your account. If you can't find the Contracts area, contact an administrator. - Your user needs permission to access and manage Contracts. Voiding a contract is restricted to administrators. - The contract must already have been generated from a template (with signers defined) before it can be sent for signature. Step by step 1. Send for signature — on a draft contract, use Send for signature. The platform freezes the document, generates a draft PDF, automatically signs the issuing company's side, and delivers the link to external signers as a card with a button in the linked conversation. At least one signer is required. 2. Resend a reminder — use Remind to re-post the signing card and button in the conversation and nudge the pending external signers. If there is no linked conversation, the action has no effect. 3. Void / cancel — use Void to irreversibly cancel a contract that was already sent. The status changes to voided and the document can no longer be signed. This action is restricted to administrators. 4. Duplicate — use Duplicate to clone the contract into a fresh draft. Signers and items are copied, a new verification code is generated and no signatures are carried over. 5. Download the signed PDF — use Download to get the signed URL of the most recent final document (falling back to the draft if there is no final yet). The download includes the SHA-256 hash so you can verify integrity. 6. Copy / share the signing links — use Signing links to get each external signer's public URL, in case you need to resend the link manually through another channel. Parties that sign automatically have no public link, and the signing token is never exposed in the list. Tracking and audit - Audit trail (events): every contract has a read-only forensic timeline with the signature lifecycle events — created, sent, viewed, OTP sent, OTP verified, signed, rejected, expired, downloaded and voided. Each event records the IP, device, consent, authentication method and the document hash at the moment of the event. The trail is immutable (append-only): no record can be changed after it is created. - Filter the list: you can filter contracts by status, signature level and, most usefully, by the support links — conversation, contact and CRM deal — plus the issuing company. This lets you quickly find every contract for a given customer or a specific deal. Archive and restore contracts - Archive removes the contract from the default list without deleting it — handy for tidying up old or closed documents. - Restore returns an archived contract to the active list. - A contract with a real signature (partially signed or completed) is a legal record and is never deleted — only archived. Permanent deletion is allowed only for a draft that is already archived. Integrations with Tasks and Follow-up From the contract itself you can trigger other modules of the platform (when enabled): - Create a follow-up Task — generates a Task already linked to the contract's conversation, contact and CRM deal. Requires the Tasks module enabled. - Enroll in a Follow-up sequence — enrolls the contract's contact into a follow-up sequence (idempotently, with no duplicates). Requires the Follow-up module enabled and a contact linked to the contract. Use cases - Close a deal in the CRM, send the contract in the same conversation and create a task to follow up on the signature. - Resend the reminder to a customer who opened but hasn't signed the document yet. - Void a contract sent by mistake and duplicate it to fix the details in a new draft. - Download the signed PDF and archive the completed contract to keep the list clean. Tips, limits & best practices - Use the audit trail to know exactly who viewed and who signed before chasing a pending signature. - Voiding is irreversible — confirm before using it. To merely fix details, prefer to duplicate and send the new version. - Always check the SHA-256 hash when downloading the final document if you need to prove integrity. - Keep the list tidy by archiving completed and old contracts. Troubleshooting - The status is stuck on "partially signed": someone is still missing. Check the audit trail to see who has signed and use Remind or Signing links to chase the pending parties. - The signer didn't receive / didn't sign the link: confirm the channel (WhatsApp/email) and the signer's contact details; resend with the Remind button or copy the signer's signing URL and send it through another channel. - The contract expired: the signing deadline passed. Duplicate the contract to create a fresh draft and resend. - I can't void the contract: voiding is restricted to administrators and applies only to contracts that were already sent. - I can't delete the contract: contracts with a real signature are never deleted — archive it; permanent deletion is allowed only for a draft that is already archived. See also - Contracts and e-signature overview - Internal and external signing - Templates, variables and auto-fill - Public contract page and validator
Automate contracts with Automations, Macros and Flow Builder
Overview The Contracts module plugs into the platform's automation engines so you can generate and send contracts hands-free, instead of clicking on every conversation. The same two actions are available in three places: - Conversation Automations — fire on an event/condition (e.g., the deal stage changed). - Macros — you run the action manually, in one click, on a conversation. - Flow Builder — the Send contract node inside a visual flow. In all of them, the platform resolves the template, the contact and the conversation from context, auto-fills the variables, auto-signs the issuing company (the contracted party) and delivers the signing link to the contact whenever a conversation is linked. Prerequisites - Contracts module enabled and a user with permission to manage contracts. - At least one contract template already created. - A contact (and, ideally, a conversation) on the trigger — that is where the signer comes from. - An issuing company registered (used as the default contracted party and for auto-signing). - To deliver the link through the channels, a WhatsApp or email Inbox. Step by step Conversation Automations 1. Go to Settings → Automation and create or edit a rule. 2. Define the event and the conditions that fire the rule. 3. Under Actions, pick one of the contract actions: - Send contract from template (send_contract_from_template): creates the contract from the template and sends it for signature right away. - Create contract from template (create_contract_from_template): only creates the contract as a draft for the agent to review before sending. 4. Set the template on the action. Save the rule. Macros 1. Go to Settings → Macros and create a macro. 2. Add the same contract action (Send or Create from template) and choose the template. 3. In the conversation, run the macro from the Macros menu to generate/send the contract manually. Flow Builder 1. In the flow editor, add the Send contract node. 2. Select the template (and, optionally, a title). 3. Connect the success output to the next step and the failure output to a fallback (e.g., notify an agent). 4. Publish the flow. On execution, the node creates the contract (auto-fills variables, builds signers/items and picks the default issuer) and sends it. Settings & options - Action parameters: template_id is required. Optionally, company_id (issuing company), crm_item_id (CRM deal) and title (contract title). When you omit the company, the platform uses the default issuer; contact and conversation come from the trigger. - Identical execution everywhere: Automations and Macros share the exact same action set, so the behavior is identical — only the trigger differs (automatic, manual or by flow). - Contract-based conditions: rules that respond to contract events can filter by contract_status, contract_tier (signature level), contract_company (issuing company) and contract_total (sum of items, in whole currency units). Available operators: equal to, not equal to, contains, does not contain, is present, is not present, is greater than, is less than. A rule with no conditions always runs; a misconfigured condition fails safe (it does not fire on everything). - Flow node outputs: success moves forward (carrying the generated contract_id); failure exits through a separate path, identified by contracts_not_enabled, contracts_template_missing, contracts_no_contact or send_contract_failed. Use cases - Deal won in the CRM → automatically send the service contract in the same conversation. - Stage change (e.g., "Negotiating" → "Closing") → create the contract as a draft for the agent to review before sending. - Flow-driven service: at the end of a qualification Flow Builder, the Send contract node issues the document and moves on to a billing step on success. Tips, limits & best practices - Use Create when you want a human review before sending; use Send when the flow is already validated and can go straight to signature. - In Automations and Macros, the actions degrade silently: if the module is disabled, the template is missing or there is no contact on the trigger, the action simply does nothing and writes a [CONTRACTS_AUTOMATION] log line — it never breaks the rest of the rule/macro. - In Flow Builder, the same issue does not interrupt the flow: it leaves through the failure output, so always connect that path to a handler. - Make sure the source data (contact, document, deal) is filled in so variable auto-fill works well. - For the contracted party's auto-signature, keep the right issuing company (and a valid A1 certificate, for qualified signatures). Troubleshooting - The rule ran but no contract appeared: most likely a missing template, a missing contact on the conversation, or the module is disabled. Check the [CONTRACTS_AUTOMATION] log line. - The contract was created but not sent: the action used was Create from template (it stays as a draft). Use Send from template to issue and send in one step. - The flow left through the failure output: read the reason — contracts_not_enabled (module off), contracts_template_missing (template not set), contracts_no_contact (no contact) or send_contract_failed (delivery error). - The signer did not receive the link: confirm there is a linked conversation and that the channel (WhatsApp/email) and the contact details are correct. See also - Contracts and Electronic Signature overview - Templates, variables and auto-fill - Internal and external signing - Issuing companies and the A1 digital certificate
Module settings and document theme
Overview The Contracts settings area brings together two groups of account-level options: the module defaults — values applied to new contracts (signature level, language, link validity, retention and region) — and the visual identity of your documents, defined in the theme designer. The same place is where you upload the account A1 certificate (for qualified signing) and the contract header logo. Settings are unique per account (one set per account): what you define here becomes the default for every contract, and each contract can still adjust specific points case by case. Prerequisites - The Contracts module enabled for the account. - To edit the settings you need administrator permission. Agents have read-only access (they can view but not change). - To use the qualified level, have a valid A1 certificate (.pfx/.p12) and its password — on the account and/or on the issuing company. - For the logo, a PNG or JPEG file (these are the formats rendered in the PDF). Step by step 1. Under Contracts, open the Settings section. 2. Adjust the module defaults (signature level, language, link validity, retention, region and reminder policy). 3. (Optional) Upload the account A1 certificate to enable qualified signing by default. 4. Set the visual identity: upload the header logo or reuse an existing logo (from an issuing company or from the Media Library). 5. Open the theme designer and adjust colors, fonts, page, footer and signatures. 6. Use the live preview: the platform renders a sample PDF with the current theme, without saving anything. 7. Save. The changes then apply to the next contracts. Settings & options Module defaults | Setting | What it does | Default | |---|---|---| | Default signature level | Level applied to new contracts: simple, advanced (with OTP) or qualified (A1). | Simple | | Default language | Language of the generated document. | English | | Default link validity | Days until the signature link expires. | 30 days | | Document retention | How many years signed documents are kept. | 5 years | | Region / legal framework | Region that drives the legal framework and the applied retention. | BR | | Reminder policy | Enables automatic reminders for pending signers and, optionally, links a follow-up sequence. | Enabled | These are only the default values: the platform starts from the code settings and layers what you defined on the account on top. When generating a contract, you can still adjust the level and other points individually. Account A1 certificate For qualified signing (ICP-Brasil), you need a digital A1 certificate — a password-protected .pfx/.p12 file. You can upload an account A1 certificate that acts as the default for the operation. Each issuing company can also have its own A1, which takes precedence for the contracts it issues. - The certificate is sensitive data: it is stored securely and never shown back on screen. - The A3 certificate (hardware token/card) is not supported in this version — only A1 (a file). Visual identity and header logo The logo that appears in the contract header follows a cascade, top to bottom: 1. Issuing company logo (if the contract's company has its own logo). 2. Account default logo (the one you set here in Settings). 3. Theme logo (an external logo URL configured in the theme designer). The account default logo can be added by upload (a file) or reused from an existing logo — for example an issuing company logo or a Media Library file — without re-uploading the bytes. When you remove the account logo, the header falls back to the company logo or the theme URL. The logo is kept separate from the JSON theme. Document theme designer The theme designer controls the entire look of the PDF. The effective theme is resolved as a cascade: system default ← account ← issuing company ← template ← unsaved designer overrides. When a contract is sent, the theme is frozen into the document, so a signed contract never changes appearance afterwards. Among others, you adjust: - Header: logo position and show/hide the company name, document (CNPJ/CPF) and address. - Brand and colors: primary, secondary, accent, heading and text colors; font (Helvetica, Times or Courier) and the body and title sizes. - Page: size (A4 or Letter), orientation, margins, border and watermark. - Footer: page numbering (position and format) and legal disclaimer. - Signatures: layout, role order, show witnesses and show the A1 seal. The live preview renders a sample PDF (with a sample company, styled clauses, an items table and a full set of signatures) without saving anything. If you point to a company and/or a template, the preview reflects the full cascade, exactly as a real send would look. If rendering fails, the preview degrades to a one-page notice — it never stops responding. Use cases - Standardize the look of every contract with your brand (colors, font and logo). - Enable the qualified level by default for an operation that always requires A1. - Tune the link validity and the reminder policy to speed up closing. - Keep different logos per issuing company, with the account logo as a fallback. Tips, limits & best practices - Keep the A1 certificate valid — an expired certificate blocks new qualified signatures. - Check the appearance in the preview before sending: the theme of a sent contract is frozen and does not change afterwards. - Use hexadecimal colors and keep the font within Helvetica, Times or Courier (always safe in the PDF). Logos in PNG or JPEG. - Only administrators change these settings; agents have read-only access. Troubleshooting - I can't edit the settings: you need administrator permission; agents can only view. - The preview shows an "unavailable" notice: the sample render failed; try again and review the theme adjustments. - The logo doesn't appear in the contract: check the cascade (company → account → theme URL) and use a valid PNG/JPEG file. - Qualified signing is unavailable: confirm there is a valid A1 on the account or on the selected issuing company. See also - Contracts & E-signature overview - Issuing companies and A1 digital certificate - Templates, variables and auto-fill - Internal and external signing - Public contract page and validator
Configure the contract messages
Overview Contracts send the customer two messages: the signature request and the signed confirmation. Here you customize each one's body per language, with no AI involved. Anything left untouched keeps the shipped Conversa Labs message. Beyond the body, you also edit the message's auxiliary labels and configure, per message type and per language, the approved WhatsApp template used when the 24h window is closed. Prerequisites - Contracts enabled on the account and administrator permission. - To configure sending outside the window: a WhatsApp Cloud inbox with templates approved by Meta. Step by step 1. Open Contracts → Settings → Messages. 2. Pick the language in the selector at the top. It opens on the account language and lists every language the installation enables (up to 40), showing how many already carry your copy ("N of M languages with content"). 3. Write the signature request and confirmation bodies in Markdown. Empty = the language's shipped message (Default badge). 4. Use variables ({x}) to insert contact, account and contract data. The picker offers only the variables that actually resolve in that message. 5. Open the Auxiliary labels block to adjust the 3 labels (captions and the button text). 6. The Outside the 24h window (WhatsApp Cloud) block shows up open, right under each message type. Pick the approved template for that type in that language, map the {{1}}, {{2}}… parameters and fill in the link button, if there is one. If no template exists yet, use Create from my text to generate one from the body you wrote. 7. Check the preview per channel, use Send test to validate it on a real conversation, and click Save messages — including after creating a template, because creating the template does not store the configuration. Restore default removes the customization on the server, not only on screen. Settings & options Languages and fallback Language is a selector with every language the installation enables. At send time, Conversa Labs looks for the copy in this order: the contact's language → the same base language (pt_BR ↔ pt) → the account language → the shipped default message. Auxiliary labels There are 3 labels (captions and the button text), in a collapsible block under the body. They follow the same language and restore rules. Outside the 24h window (WhatsApp Cloud) The block appears open and inline right under each message type — it is not a section you have to expand. The template is per message type and per language — request and confirmation each have their own, instead of a single template for the whole module. It gives you: - Pick the approved template from the catalog. - Sync from Meta and Create from my text are always visible. When the action is unavailable, the button appears disabled with the reason written next to it: the inbox is not WhatsApp Cloud, the account does not have the WhatsApp Inbox Suite, or your profile does not manage inboxes. - Sync from Meta refreshes the list of approved templates. - Create from my text generates the template from that type's text in that language, submitting it to Meta as a UTILITY template, converting each {{ variable }} into {{1}}, {{2}}… and pre-mapping them. With no text to generate from, the button is disabled and the screen asks you to write the text first. - After submission the template is not approved yet: it appears in the selector marked awaiting approval and only starts delivering once Meta approves it and you sync. Submitting again with the same name replaces the pending draft instead of failing. - Creating the template does not save the configuration — click Save messages to store the mapping. - The {{n}} parameter mapping and the link-button field — ideal for taking the customer straight to the signing link. - Native "Sign" button: the signature request goes out with a real button on WhatsApp (Cloud and Web). Before, the link went out as a loose second line of text — the button the screen promised never reached the customer. Turn it off under Delivery → Native buttons; the button text and the line above it stay editable under Auxiliary labels, per language. - Delivery: picks which WhatsApp inbox's approved-template catalog is browsed. Everything that depends on that inbox — why syncing/creating is unavailable, how many templates were filtered out, the link to manage them, and the Sync from Meta button — is stated once there, not repeated under every message. The send still leaves through the conversation's own inbox. Templates whose header requires media or a variable are not listed here — this send has no way to fill that header — and the screen states how many were left out. They remain usable from the inbox's own Templates tab, linked directly from this screen. Notes: WhatsApp Web (WazMeow) has no 24h window (the block does not even appear); 360dialog can select a template but cannot create one; Meta matches name + language + approved, so a template in the wrong language is flagged on screen and would be rejected on send. Preview and test send The preview is rendered server-side, per channel, and shows only the channels the account actually has. It also displays the resolved out-of-window template, with the values each parameter will carry. Send test delivers the message to a chosen conversation honouring the 24h window: with the window closed and no template configured, the test is skipped with the reason stated on screen. Contract variables Beyond contact, account, conversation, inbox, agent, CRM and organization — which now really render — these messages offer the contract's own data: | Variable | Replaced with | |---|---| | {{ contract.title }} | Contract title | | {{ contract.status }} | Current status | | {{ contract.signature_tier }} | Required signature tier | | {{ contract.expires_at }} | Deadline to sign | | {{ contract.counterparty }} | Counterparty | | {{ contract.sign_url }} | Signing link | | {{ contract.verification_url }} | Document verification link | Relationship with the module settings These messages are distinct from the module settings (default signature, retention, A1 certificate) — here you only change the customer-facing copy. Tips, limits & best practices - Markdown per channel: attachments drop on LINE/TikTok/X; raw HTML disappears in email/widget; *bold* on WhatsApp shows as a pair of asterisks. - Configure the out-of-window template in the same language as the body — they are pairs, not a single global setting. - In the signature request, always include {{ contract.sign_url }} (or use it in the template's link button) and the deadline via {{ contract.expires_at }}. - After "Create from my text", the template sits awaiting approval at Meta — use Sync from Meta to see when it is approved and starts delivering. Troubleshooting - It went out as the default: the type was empty (Default badge) in that language, or the contact's language has no copy and the fallback reached the shipped default. - Nothing sent outside the window: confirm the approved template for that type in that language. - The template shows as flagged: it is in a different language from the message — swap it for an approved one in the right language. - "Create from my text" is disabled: the reason is written next to the button — the inbox is not WhatsApp Cloud (on 360dialog you pick an already-approved template), the account does not have the WhatsApp Inbox Suite, your profile does not manage inboxes, or there is no text in that type and language to generate the template from. - I created the template but it doesn't show up / isn't used: right after submission it sits awaiting approval — it only delivers once Meta approves it and you use Sync from Meta. Also confirm you clicked Save messages: creating the template does not store the configuration. - I can't find a template in the list: templates with a media header or a header variable are not listed here; use them from the inbox's own Templates tab. - The test send was skipped: the conversation was outside the 24h window and the message had no template configured — the screen states the reason. See also - Contracts module settings - WhatsApp Inbox Suite: Templates, Flows and Calls