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...
19450
Want to shape the future of Docusign? Add your ideas for dream features and upvote others you love.
In the era of widespread AI tools (LLM), there is growing concern in legal, compliance, and financial workflows about whether the content of an agreement, contract draft, or official correspondence was genuinely written and reviewed by a human — or largely generated by AI.Currently, DocuSign excels at verifying the recipient (signer) through biometric authentication, liveness detection, and ID verification. However, there is no equivalent mechanism for the sender/author to cryptographically attest that they personally created or reviewed the content before sending.Proposed Feature:Add an optional (or configurable per template/account) pre-send biometric attestation step for the sender:When the sender finishes editing a document/envelope (especially for high-stakes items like contracts, NDAs, payment instructions, legal correspondence, or compliance documents), they are prompted to confirm authorship with a quick on-device biometric check: Face ID, Touch ID / Fingerprint, or facial recognition with liveness detection. Upon successful confirmation, the system generates a cryptographically signed attestation (e.g., “Human Authored + Biometric Attestation”) containing: Hash of the document/content at the time of confirmation Timestamp Sender’s identity (linked to their verified account) Proof that a live human performed the biometric confirmation (without storing raw biometric data — using on-device secure enclave where possible) This attestation is embedded into the envelope as metadata, visible in the audit trail, and can be verified by the recipient or auditors.Key Benefits:Provides positive proof of human authorship in addition to existing AI content labeling. Strengthens non-repudiation and trust in sensitive communications. Helps organizations comply with emerging regulations (e.g., EU AI Act requirements for transparency on AI-generated content) by offering clear evidence that a real person stood behind the text. Low friction: the step can be enabled only for sensitive templates or high-value envelopes, taking just 2–3 seconds. Privacy-friendly: biometric processing happens on-device; only a cryptographic token is attached.This feature would complement DocuSign’s existing strong identity verification for signers and position DocuSign as a leader in trust and provenance for the entire agreement lifecycle — not just the signing moment.I believe this would be especially valuable for law firms, banks, corporate legal departments, and any organization dealing with regulated or high-risk documents.No compensation or recognition is requested — I simply want this idea to have a chance to live and be considered. I think I will purchase license to use it in my Outlook also :).
After configuring the permissions by User, Group, Agreement Set, etc -- it would be helpful to be able to verify the permission on an Agreement or User. “Who sees What” function. Download permissions to a CSV -- one user per line -- would be helpful. Ability to check an Agreement -- “Who can see/edit?” Thanks,Mike Mathewson
Love the Idea of the Mark-up Tool but needs a few advancements.Line option - make available for recipients also (put the option under the comments option.) Move the Mark-up option (while in recipients hands) from the [Other Actions] button to under Add Comments icon. Currently if recipient adds Mark-up to document, next signer cannot visually see what was covered. Within the document, wherever there was a Mark-up added: add an Icon to the left of that Mark-up and add a feature where the next signer can click on that icon and the mark-up will briefly disappear. This will allow all parties to view the original language. While other parties can edit other people’s mark-ups, you can delete all, change and revise, however, you can only change or revise within the size of the original mark-up’s box size. Allow this to be resized. Require all signers to initial mark-up. Any Changes to mark-up, needs to be rerouted to all who have not seen. (similar to the collaborative option of text fields) Allow any user to reject just the Mark-up...or allow it to be deleted from another signer Allow SENDER to change mark-up formatting if they want, particularly Font Color.
Please create an Add Note button in the Overview tab of an Agreement Desk Request. We need the ability to add general notes/status updates and have them appear in the Activity Feed. These notes don’t require action by or notice to specific people so the Send Message does not apply. Being required to Send Message to add a general note to the Activity Feed creates unnecessary steps, 1) drafting an email to yourself or shared mailbox, 2) opening and deleting the email from your inbox, and 3) clutters up the Activity Feed - when all we want to do is enter short notes providing updates. We have the ability to do this in our current tool so this feels like a step backward for us. This is another lacking feature that we did not see in a demo and did not have access to a sandbox to test prior to purchase. ia the Send Message button.
Hello Ideas team,We advice all of our customer migrate to new send view as this document told:https://www.docusign.com/blog/developers/esignature-rest-api-embedded-correct-view-updated?msockid=13eac2ad5d496fc10dc3d62c5c416ee9and also can find the document:https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopeviews/createsender/we find the setting as below:{ "returnUrl": "<url>", // URL required "viewAccess": "envelope", // required "settings": { "startingScreen": "Prepare", // (default) or "Tagger" "sendButtonAction": "send", // (default), "redirect" "showBackButton": "true", // (default), "false" "backButtonAction": "previousPage", // (default), "redirect" "showHeaderActions": "true", // (default), "false" "showDiscardAction": "true", // (default), "false" "lockToken": token_value, "recipientSettings": { "showEditRecipients": "true", // (default), "false" "showContactsList": "true" // (default), "false" }, "documentSettings": { "showEditDocuments": "true", // (def,ault), "false" "showEditDocumentVisibility": "true" // (default), "false" "showEditPages": "true", // (default), "false" }, "taggerSettings": { "paletteSections": "default", // (default), "none", "custom" "paletteDefault": "custom" // "merge", "notary", "seals", // "smartContracts", "annotations", // "smartSections" } } }}Now the customer want add validate parameter for send button. We can define paramter for signature in the setting, so it will check whether the sender have drag signture for every signer before send. sometime the sender forget drag signature for other signer except the first one. if the sender not drag, will throw the error that he need to drag the signature for which signer. FreeLink/甫连信息🌍 DocuSign Partner | Partner Profile🌟 The only DocuSign Partner globally certified as both a Certified eSignature Administrator and eSignature Technical Consultant🏆 DocuSign 2024 APAC Reseller Growth Partner of the Year💡 Ranked #1 in the OG All Star category in DocuSign Community Wrapped 2024📊 DocuSign Community Leaderboard Top 5 contributor🚀 Expertise in DocuSign integrations with on-premises systems for leading enterprises across various industries🔗 Connect with me on LinkedIn: https://www.linkedin.com/in/gehengfeng/
When you use the copy button it would be valuable to be able to see which envelope the new envelope was copied from. In my opinion, something should tie those envelopes to each other for reference. We can’t find any ties between them even via the API and metadata. It doesn’t show anything in the envelope history or certificate of completion noting that the envelope was copied (yet).
We want raise enhancement request for adding RecipientIPAddress attribute as part of JSON connect event through Webhook. Currently this attribute is as part of XML event that follow SOAP API. But we want that field to be included in the Docusign JSON event that follows REST API schema.
We are capturing date fields on a Web Form as part of a Maestro Workflow. We are pushing the date fields collected into Salesforce. Salesforce has validation rules on some fields that will not allow dates that are in the past.This will cause the Maestro Workflow to fail upon SF Update and/or the Salesforce processing to fail.We would like to see the ability to allow restrictions on the Date field (e.g. current and future dates only)
Similar to Envelope Custom Fields and the way they show up on Envelope Reports, we would regular text/tab fields to also have the option to display on reports, as we have key identify features like ‘Loan Number’ or ‘Member Number’ we would like to include. This should also extend to Powerforms, as we’re currently utilizing this for most of our processes, which makes ECF not an option.
Description:Currently, redirect URLs can only be configured at the Account or Brand level through the “Destination URL” setting, or dynamically specified when generating an embedded signing view.However, for email-based signing, there is no option to define a per-recipient redirect URL when creating an envelope via API.In some business scenarios — for example, our customer needs to have external merchants sign agreements — they would like each signer to be redirected to a custom application form or confirmation page after signing.We have tried: Embedding the form link in the email body → but since the domain differs from DocuSign’s, this often triggers mail security gateways and increases the chance of messages being quarantined or blocked. Using the Brand-level Destination URL → but this applies globally across all envelopes and recipients, which is too broad and affects other workflows. Therefore, we suggest enabling the ability to specify a recipient-level redirect URL at the time of envelope creation, similar to how embedded signing supports returnUrl.Additionally, it would be very helpful if this redirect could be triggered immediately upon completion of signing, even for standard email-based flows — to provide a smoother, more seamless end-user experience.Benefits: Enables finer-grained control for different workflows or recipients; Reduces email deliverability risks by avoiding external links in the signing email body; Provides a more integrated experience between DocuSign and customer business systems. FreeLink/甫连信息🌍 DocuSign Partner | Partner Profile🌟The only DocuSign Partner globally with two Certified eSignature Technical Consultants🏆 DocuSign 2025 APAC Growth Engine Partner of the Year💡 Ranked #1 in the OG All Star category in DocuSign Community Wrapped 2024📊 DocuSign Community Leaderboard Top 5 contributor🚀 Expertise in DocuSign integrations with on-premises systems for leading enterprises across various industries🔗 Connect with me on LinkedIn: https://www.linkedin.com/in/gehengfeng📬 For business inquiries, feel free to connect via :WeChat/微信: +86 1381880287WhatsApp: +65 97796938
Title:Description:According to the current process, if an SMS subscription needs to be revoked within 7 days, customers must open a Support Case and wait for the Docusign Support team to process the request.For customers with large and growing envelope volumes, this creates several challenges: Users may accidentally subscribe SMS authentication, but they are not immediately aware of the mistake. By the time they realize it, the SMS subscription link has often expired, making recovery more difficult. Submitting a Support Case for each incorrect subscription introduces significant operational workload, slows down business processes, and reduces overall system usability. We would like to propose adding the ability for account administrators to directly revoke SMS subscriptions through the Docusign Admin Portal or via API — without requiring intervention from the Support team.Benefits of this enhancement: Dramatically improves efficiency for high-volume enterprise customers; Reduces reliance on manual Support cases and shortens the response cycle; Minimizes business disruption caused by accidental SMS subscription issues; Enhances the overall self-service capabilities of the Docusign platform. Providing an online, self-service revocation option would significantly improve the customer experience and reduce operational friction for organizations that rely heavily on SMS authentication. FreeLink/甫连信息🌍 DocuSign Partner | Partner Profile🌟The only DocuSign Partner globally with two Certified eSignature Technical Consultants🏆 DocuSign 2025 APAC Growth Engine Partner of the Year💡 Ranked #1 in the OG All Star category in DocuSign Community Wrapped 2024📊 DocuSign Community Leaderboard Top 5 contributor🚀 Expertise in DocuSign integrations with on-premises systems for leading enterprises across various industries🔗 Connect with me on LinkedIn: https://www.linkedin.com/in/gehengfeng📬 For business inquiries, feel free to connect via :WeChat/微信: +86 1381880287WhatsApp: +65 97796938
Most of the document are legally approved documents and should not be edited. Requesting for a Docusign enhancement where the user can adjust the height of the standard and/or custom fields to enable developers to use fields in limited/narrow spaces without the fields overlap the document text.
When document visibility is turned on for any organization, the ability to fax envelopes is disabled.I would like to propose an enhancement that allows fax functionality to remain available when document visibility is enabled.This improvement would greatly benefit our organization by enabling us to send multiple documents in the same envelope with the document visibility selection options, and still fax envelopes as needed to support our customers.Thank you for considering this request.Brandy





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