How to Use the Ideas Feature
What you need to know about Docusign Community IdeasThis guide will walk you through the process of sharing your ideas, voting on existing ideas, and...
21380
Want to shape the future of Docusign? Add your ideas for dream features and upvote others you love.
The fields containing "This page is reserved and intentionally contains no content" will not block the underlying area of the PDF once the envelope is completed. It only does for the signer. The final PDF should have the same area hid that the signer sees hidden.From a signer's perspective, the field is working as expected. see attached
Although there is a report to export Envelopes history, it only includes Names and email addresses. It would be helpful to have an export available for Contacts as the list is built interactively and includes phone numbers. Just saying...
Hi, Since we use both eSignature and CLM module from DocuSign under one contract, we would like to check the envelope volumes used by each module for planning & budgeting purpose, but the current DocuSign standard report shows only total view of used envelopes for both modules, not splitting the view. It would be nice to have the reports for two separate modules.
We need a system that would allow one person to enter their unique personal id during signing and that is then captured as metadata in the digital signature certificate Case 16441690
Problem / LimitationCurrently, Docusign allows the use of ECF (Envelope Custom Field) placeholders in the Email Subject line using syntax such as:[[ECF:Client_Name]] However, ECF fields and standard merge fields (text, number,...) are not supported in the Email Message Body, including: Next Sender recipient emails Routing Order notifications Automated system emails tied to envelope progress This creates an unnecessary inconsistency: dynamic data can be shown in the subject, but not in the email body where context matters most.Why this mattersCustomers frequently need to include dynamic, envelope-specific information in the email body, such as: Client or account name Contract reference number Opportunity ID Agreement type or region Internal tracking codes Without merge support in the email body, customers must: Use vague, generic messages, or Build complex workarounds (Workflow Builder (formerly Maestro) workflows, external email systems, or manual intervention) This reduces usability and adoption—especially in IAM workflows where automation and clarity are critical.
ProductDocusign IAM (Agreement Preparation / Agreement Builder)Idea / Enhancement RequestCurrently, the Docusign Clause Library is available primarily in CLM scenarios, but it is not usable within IAM Agreement Builder or generation flows when working with conditional or dynamic clauses.In IAM: Conditional logic can insert or paste static text Clause content must be hard-coded or duplicated There is no option to select a clause from the Clause Library via a lookup field This limits reuse, governance, and consistency across agreements.Proposed EnhancementExtend the Clause Library so it can be used: During agreement generation Inside the Agreement Builder, including conditional logic Specifically: Allow users to select clauses from the Clause Library via a lookup/dropdown field Insert the selected clause dynamically into the agreement Preserve clause metadata (name, version, owner) Support conditional logic (e.g. jurisdiction, contract type, customer segment) Instead of pasting static text, users should be able to reference managed clauses.Why This MattersWithout Clause Library support in IAM: Clauses are duplicated across templates Legal loses control over clause versions Updates require manual changes in multiple places IAM falls short of basic CLM expectations Example Use Case“If country = Germany → insert German liability clause from Clause LibraryIf contract value > €50k → insert extended indemnification clause (latest approved version)”SummaryIAM Agreement Builder should support dynamic clause selection from the Clause Library, not just static text insertion. This is essential for scalable, enterprise-grade agreement creation.
Please enable DocuSign Identity Wallet in Salesforce so that user’s don’t have to identify themselves everytime when they need to sign a document that requires ID verification. Why is the button “Use Identity Wallet” displayed as an option when I open the evenlope in Salesforce to sign the document without opening the DocuSign Webconsole, but it actually is blocked to give access to the Identity Wallet? I get that the access via an iframe is a high security risk but why would you even show it as an option if it doesn’t work? Otherwise why doesn’t it just open the DocuSign Webconsole where the user is actually able to access the identity wallet and make it easy and less clicks for the user?
When a witness opens an envelope to witness/sign, they are presented with a screen in which they have to enter their Occupation and Address details. These fields are mandatory and the witness must complete these details before they can open the envelope to complete/sign/witnesses the document(s). It would be useful if these fields could be available to the creator of the envelope when they are adding fields to documents so that these details are auto filled into the document once completed by the witness. Currently, if the witness name, occupation, address etc. are required information on the documents the creator has to create text fields for these and the witness has to re-key this information into the document after they have already entered these details on the mandatory screen when accessing the envelope. This can result in the witness updating the text fields to say: as already entered etc. and the document not being populated with the required information. We are using tooltips in an attempt to resolve this issue but witnesses continue to complete the document fields in this way. Is it possible to make these fields available (like the Company, Title fields we have for standard users)?
Having a workflow to be able to retrieve documents that are still valid but has been voided as it has expired. Like having all parties involved sign to attest that the document or the deal is still valid.
When a file is uploaded to an envelope and automatic template matching is set it will apply a matching template to the first occurance of the template match in the document and ignore any others. In the work our business does it is possible that there are multiple pages exactly the same except for minor details (not in the IDR zone). Currently Template matching only happens to the first occurance of the page the template matches. It would save so much time for us if the template matching algorithm would allow for multi page matching!
Currently, DocuSign does not allow umlauts in email addresses when sending envelopes and does not support this format.However, it is possible to generate email addresses with umlauts, especially in Germany. Therefore, the customer request or idea is to technically support umlauts in email addresses (particularly in German) requires DocuSign to implement this functionality.This idea would be helpful so that more signatories can use DocuSign. All users in Germany and other countries would benefit if the feature were extended to include other country-specific features.
As a financial institution, we do not want our clients to have access to pre-selected signature styles to sign our documents. Our goal is to have each signature drawn - as you can understand the need to verify closest to real signatures in a financial setting is crucial. I have found that the only way to achieve this is to customize it on the envelope level each time we send. This would be fine, except the signer is then forced to re-draw their signature on every line they need to sign on within the envelope. This is not the customer experience we want. We would like a global account setting that blocks all previsouly set pre-selected signature styles and only requires our signer to create their drawn signature on the first signature field, filling it in for them after that until completion of the envelope. We send out many complex accounts for businesses and need this process as streamlined and compliant as possible.
Hello,I would like to report a graphical issue that appears at the end of the document signing process when the system is configured to allow payment as well.Specifically, on the Stripe payment screen localized in Italian, there is a display issue. We suggest simply changing the text to "Carta" (simple translation for Credit or Debito Card), as shown in the screenshot below. Daniele
There should be an option to set whether or not the context for fields in the document appears for the recipient. In other words, I would like to be able to set in the properties of a field that the context for this field does not appear (context that specifies whether the field is optional or mandatory).





Docusign Community
Code of ConductAlready have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK