Skip to main content

    Filter by Idea status

    Filter by category

    1017 Ideas

    L.WojciechowskiDocusign Employee

    CLM - Modernized Search - Improve Search to Handle Case and Quote Variations in Phrase SearchesIdea Submitted

    Problem / User Pain Users performing exact/phrase searches in CLM can miss relevant results when the document text differs from the query by:Case (e.g., searching agreement's records vs. document text AGREEMENT’s records) Punctuation style (e.g., straight apostrophe ' vs. curly apostrophe ’, and straight vs. curly double quotes)This is especially confusing in quoted phrase searches, where users expect “exact phrase” matching but not failure due to common formatting differences introduced by OCR or word processors. User Expectation Because CLM functions as a document repository, users reasonably expect search behavior similar to word processing tools:Curly and straight quotes/apostrophes should be treated as equivalent for matching. Exact/phrase search should support a case-sensitivity toggle, so users can choose whether case must match exactly.  Proposed Enhancements Case-Sensitivity Toggle for Phrase Searches Add an option (e.g., checkbox or advanced search setting) to enable/disable case-sensitive matching for exact/phrase searches. Example: Allow "agreement's records" to match AGREEMENT’s records when case-sensitivity is off. Normalize Quote/Apostrophe Variants in Search Matching Treat punctuation variants as equivalent during indexing and/or query parsing: ' and ’ " and curly double quotes (e.g., “ and ”) Ensure phrase searches do not fail solely due to punctuation style differences.   BenefitsMore intuitive and consistent “document repository” search experience Fewer false negatives in search results (especially in OCR-derived text) Reduced support burden and improved user confidence in CLM search accuracy  Interim Workarounds (until implemented)Remove quotation marks to broaden results Try both curly and straight apostrophe styles when searching exact phrases [Internal reference: 16843931]

    MTDobsonNewcomer

    Improve Limit Document Visibility (LDV) Defaults and Grid for Safer and More Flexible Document SharingIdea Submitted

    Idea Summary:As a law firm regularly sending highly confidential documents, we rely heavily on DocuSign’s Limited Document Visibility (LDV) feature. However, the current configuration presents a risk of unintended document exposure due to default settings and limited sender control. I propose a change to how LDV behaves to improve user experience, reduce risk, and enhance platform flexibility.Background & Context:We use DocuSign eSignature and have explored LDV settings extensively with support (Case #15948495). Francis from support has been excellent in explaining the nuances, but the current behavior still poses challenges.There are two key LDV-related settings:Drop-down: Document Visibility Off Must Sign to View, Unless Sender Must Sign to View, Unless Member of Sender’s Account Sender can set either of the above Checkbox: Allow Sender to Specify Document VisibilityThese settings influence the Document Visibility Grid (Matrix) during envelope setup.Problem:There are two risky scenarios based on sender assumptions: LDV is OFF but assumed ON → Recipients may see documents they shouldn’t.Potentially serious consequences, especially in legal contexts. LDV is ON but assumed OFF → Recipients may not see documents they should.Less severe, but still problematic. Currently:If LDV is OFF, the grid is editable, but the sender must take action to restrict visibility. If LDV is ON, the grid becomes read-only, and there is no way for the sender to override visibility and enable LDV —even if needed—without adding fields to every document for every signer (which is impractical for large envelopes).Proposed Enhancements: Make LDV Default Configurable but Always Editable: Allow LDV to default to ON or OFF based on admin preference. Always allow the sender to override visibility during envelope setup (unless explicitly restricted by admin). Improve Grid Behavior: Keep the “Allow sender to specify document visibility” checkbox functional regardless of LDV default. Make the Document Visibility Grid read-write in all configurations where sender control is permitted. Clarify that the checkbox relates to the Grid functionality. Benefits:Reduces risk of unintended document exposure by allowing LDV to be enabled by default, but disabled by the sender where required.   Improves sender control and flexibility. Enhances user experience by avoiding unnecessary workarounds. Aligns with best practices for secure document handling.Discussion Invitation:Would love to hear from others—especially those in legal, healthcare, or finance—who rely on LDV. Have you faced similar challenges? How are you currently working around this? Would these changes help your workflows?

    SB.BCTNew Voice

    X-DocuSign-Act-On-Behalf does not allow creation of envelope viewsIdea Submitted

    When you attempt to create an envelope view using the X-DocuSign-Act-On-Behalf header you get the following error:{ "errorCode": "ACT_ON_BEHALF_USER_NOT_ALLOWED", "message": "An 'Act on Behalf Of' user is not permitted for this operation."}I replied on a different post about this same issue (Attempting to create a Sender View using Shared Access fails: ACT_ON_BEHALF_USER_NOT_ALLOWED | Community), however it is marked as solved though I don’t believe it really is as the “solution” was to use an admin account, as admin accounts can always create sending views for any envelope for any user in the account, but this has some issues because it’s not like you can make everyone an admin. The issue I am facing is that in our system we allow creation of sender views for the users own envelopes, we also respect shared access allowing a user to see any envelopes created by other users who they have been granted shared access to through DocuSign. However, we cannot let a user edit an envelope that was created by another user. As that other post suggests, we could use an admin account to allow this, however that has some issues. Firstly that view will have full access to that envelope within the view so can potentially do things they should not be allowed to, for example if they have shared access at the “edit on behalf of” permission, they can should be able to edit but would not be able send, but as it was created via an admin account the send button will be available. They will also lack the banner on top of the page making it clear they are acting on behalf of the other user, e.g.:The most important thing is that when you generate a view in this way, the envelope history lacks the audit information indicating that it was being carried out by an additional user on behalf of the envelope owner and would always show as the admin user performing the edits meaning you lose any history of who performed the actions on the envelope.  As this functionality is available in the UI already, can this not be added into the envelope view APIs to allow sending the X-DocuSign-Act-On-Behalf header to allow correcting creating sending views when acting on behalf of another user who has provided shared access?

    Enhancement Request: Granular Control for Knowledge-Based Authentication (KBA)Idea Submitted

    Currently, Knowledge-Based Authentication in DocuSign is an all-or-nothing setting at the enterprise level. We have business use cases where KBA is essential for certain documents, but not for all outgoing envelopes. Having more granular control would significantly improve usability and efficiency.Proposed Enhancements:Default KBA on All Outgoing Envelopes with Override OptionKBA should be enabled by default for all outgoing envelopes, with the option for the sender to remove it when it is not required. This shifts the decision-making to the sender, ensuring that sensitive documents are always protected unless explicitly exempted.Profile-Level Default SettingsAllow KBA requirements to be set based on user profiles or roles. This would enable departments or teams handling sensitive information to have stricter controls, while other teams can operate with fewer restrictions.Internal vs. External SignersProvide an option to automatically disable KBA for internal signers (e.g., employees using company email domains) while keeping it enabled for external recipients.Template-Level ConfigurationAllow KBA defaults to be set at the template level. This would ensure that documents using specific templates automatically have the correct security settings applied without manual intervention.Conditional Logic Based on Document Type or MetadataEnable rules where KBA is triggered based on metadata such as document type, sensitivity classification, or department origin.Reporting & Audit ControlsAdd reporting features to track when KBA was enforced, who disabled it, and for which documents, to maintain a full audit trailsAPI Support for KBA ControlsProvide granular API endpoints to manage KBA settings programmatically for automated workflows.

    SSobkaNewcomer

    Enable SMS Delivery to VOIP & Short Code NumbersParked

    Problem:Many of our clients and their representatives rely on cloud-based or on-premises VOIP phone systems (e.g., RingCentral) for SMS.  Currently, DocuSign’s SMS service cannot deliver to these numbers, citing “VOIP not supported due to security...” even though those platforms accept messages sent from standard short code phones. Why This Matters to Our Law Firm:SMS has become the preferred communication/notification channel for many clients. Clients often ask us to send “consent to sign” texts on their behalf; they may have VOIP numbers. Failing to reach them by SMS delays closings, jeopardizes deadlines, and forces inconvenient workarounds (email links, phone calls) they don’t want to deal with.Evidence & Competitive Impact:We successfully received verification codes and SMS via short code on the same RingCentral number that DocuSign SMS fails to reach from HIPPA complaint vendors. DocuSign competitors such as Adobe Sign, by contrast, supports SMS delivery to VOIP numbers; clients are already asking us to switch.Proposed Feature Request:Whitelist major VOIP providers (RingCentral, 8x8, Zoom Phone, etc.) in DocuSign’s SMS routing. Enable short-code delivery to any SMS capable number, regardless of whether it’s identified as VOIP. Offer diagnostic logs for failed SMS, showing provider responses available to me directly without going through the support channels. (this transparency speeds troubleshooting.) Communicate roadmap and expected timeline.Business Benefits:Improves customer satisfaction and retention in legal/financial sectors that mandate SMS OTP. Reduces help-desk tickets and support costs by eliminating “unsupported number” errors. Prevents revenue loss to competitors who already support VOIP SMS.Please prioritize this enhancement in your product roadmap. Without SMS support for VOIP, our firm and many others will be forced to migrate to other platforms that meet our business needs.