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...
22860
Want to shape the future of Docusign? Add your ideas for dream features and upvote others you love.
Dear DocuSign team,Our company consists of several legal entities (e.g., Allseas Brasil, etc.). When a signer completes a document, they may need to enter different company names depending on the contract. We have identified the following problematic behaviour:1. When a signer manually fills in the signing company field during signing (e.g., “Allseas Brasil”), this value is automatically written back to the user’s DocuSign profile in the Company field.2. During the next signing session, the signing company field in new documents is automatically pre‑filled with the value saved in the user's profile. If the signer does not notice this auto‑populated value, the document may be signed with the incorrect company name, which creates legal and compliance risks. Although the signing company field can be manually corrected by the user, not all signers pay attention to the pre‑filled value.We got an official comments from the DocuSign Support:Auto-population: The Company field will auto-fill from the recipient's profile if available; otherwise, it is left blank for manual entry. Auto-update: There is no setting to prevent the user's profile from being updated with new Company information entered during signing. Workarounds: No official workaround or setting is documented to disable either behavior. We would like to request if it is possible the following to be added as standard functionality: the ability to disable the auto‑population of the Signing Company field during signing sessions (i.e., prevent it from being prefilled from the user’s profile) and to prevent the Company field in the user’s profile from being automatically updated based on what the signer enters in a document.Kind regards,Arina SledinaBusiness Application ConsultantAllseas
Docusign Web Forms currently support a basic, single-column layout for form fields. While this works for simple forms, it limits design flexibility and results in unnecessarily long forms — especially on desktop or tablet devices.Layout/UI improvement requests:Multi-column layouts: Allow 2-column or 3-column grids for placing fields side-by-side (e.g., first name / last name, city / postal code). Drag-and-drop visual layout builder: WYSIWYG editor for arranging fields visually on a grid instead of strictly top-to-bottom. Snap-to-grid functionality and column resizing. Custom styling & spacing controls: Padding/margin options between fields. Divider lines or subtle background colors for sections. Optional custom CSS or style presets (aligned with company branding). Better and flexible upload attachments buttons (as it is in eSignature templates)Flexible field grouping and sectioning:Create sections or panels with titles, borders, or collapsible headers for better organization.Option to display groups horizontally (e.g., “Address details” as a 2-column block). Dynamic progress bar / step indicator: Show which section or page a signer is on within a multi-step form.Customizable branding themes: More control over colors, fonts, and headers beyond the current limited template.And much more...
The DocuSign User Interface in the Agreements view is able to show whether an email has a Delivery Failure. This is under the Sent status / category. However, since there is a delivery failure that recipient has not received the envelope, therefore the envelope is really NOT sent in the business sense. Today, the business thinks that everything OK when it is clearly NOT OK. And we do NOT want to rely on a report. The DocuSign Connect callback JSON shows the happy envelopeSummary.status ="envelopeSummary": {"status": "sent",This does not follow the traditional ‘lookout below’ pattern, where at the highest level the payload indicates there is a problem with the envelope, and if you want more details, you must dig deeper into the payload. And yes! There is detail below. In the JSON Connect payload it states there is a problem inside one of the recipients.signers object: "status": "autoresponded", "autoRespondedReason": "smtp; 550 5.4.1 Recipient address rejected: Access denied.\n [LN2PEPF000100CD.GBRP265.PROD.OUTLOOK.COM 2025-02-05T11:17:05.398Z\n 08DD3E4205AB062F]",The DocuSign platform knows how to catch this issue and has mapped this as Delivery Failure in the UI layer. Therefore, the envelopeSummary.status IDEALLY would be mapped to ‘Delivery Failure’ or a more general ‘Error’ status, and our code would catch this, and then navigate to the next level down to the recipients.signers[*].status to test each recipient’s status. Plus, we have to test every type of recipient. Ouch.We general do NOT like to look at the lowest level first as that is not performant. I am sure the DocuSign UI would like this too.
the customer want to add pause node in the signing flow. like routingOrder is 1,2, 3. and they can add a pause between 1 and 2 or 2 and 3.the need some one approve then use the API to restart the flow again. thanks. FreeLink/甫连信息🌍 DocuSign Partner | Partner Profile🏆 2024 APAC Reseller Growth Partner of the Year🔧 The first in APAC to pass the DocuSign eSignature Technical Consultant certification.🚀 Expertise in DocuSign integrations with on-premises systems for leading enterprises across various industries.Feel free to reach out for collaboration opportunities.
Hello Docusign Product Team,I would like to extend the time for deleted envelopes and make them trackable since some envelopes are very important to me, and I am not able to see what happened.If possible, allow the admin to determine who can delete the envelopes or not, since some envelopes are important and must never be deleted.These enhancements are vital for me, and I truly believe that Docusign will make some changes since the delete option is very limited.I appreciate your attention.
Add a new configuration to the ‘Signing Settings’ page to address the security flaw of being able to forward envelope email notifications to someone else. Forwarding the email allows this person to sign on behalf of the intended signer. Existing setting: “Prevent users from forwarding completed envelopes”New setting: “Prevent users from forwarding envelopes’ If this forwarding allowance is a requirement of being able to delegate another signer, perhaps they should be tied together:Existing setting: “Allow recipients to change signing responsibility” New setting: “Allow recipients to change signing responsibility and forward envelopes” - leaving this blank would produce an error if the user tried to open a forwarded envelope. The solutions I’ve read for this to ‘simply add ID verification’ is not a viable solution because this cannot be enforced at the global account level. There’s too much responsibility on the sender and we’re not ready to retrain the entire organization to always add Access Codes.
I was told in a case that there is no ability to download/upload PowerForms from demo to prod. You have to download the template from demo, upload it in prod, then recreate the PowerForm in PROD.This needs to have the ability to download the powerform. Anytime you have to manually build in prod you can have mistakes. We need the capability to download/upload PowerForms.
Hello,We are using Docusign integration with our Document Management System. We noticed that signer can add any metadata field instead of Signature field and then Finish button thus allowing to complete signing task.We had conversation with Docusign support via this ticket CaseDetail but support didn’t offer something useful.
Checkbox and RadioGroup fields show "X" instead of checkmark or filled circle in final signed PDF
When recipients select Checkbox or Radio Button fields, the completed/signed PDF displays an “X” as the selection indicator.In many business and compliance scenarios, a tick mark (✓) is the expected standard and looks more professional. An “X” can sometimes cause confusion or appear as a rejection.Request:Please add an option at the account or envelope level to choose the selection style (✓ or X) for completed PDFs.This would improve clarity and better align with common form standards.
I have a field that needs to have a % at the end. On a template, I can make a field number that has a $ at the beginning, but not one that has a % at the end. I saw some documentation using doc gen to make that happen, but we don't have doc gen. Would you please incorporate the functionality that doc gen has into template fields for this.Thank you
Product AreaseSignature / API / ConnectProblemHigh-volume senders (e.g., >1,000 envelopes/day) frequently face “recipient didn’t receive email.” Today we must open Support cases to confirm whether the recipient’s mail server returned SMTP 250 (accepted). This creates a compliance loop (customer consent), long MTTR, and heavy manual workload (~1% delivery exceptions already strain teams). Delays impact our customers’ business and increase complaint risk.Proposal Envelope History: Email Delivery pane Show per-recipient metadata only: accepted (Y/N), smtpCode (e.g., 250), masked smtpMessage snippet, acceptedAt timestamp masked mxHost, tls (Y/N), retryCount, bounceCategory (soft/hard/other) Controls: admin-toggle, configurable retention (30–90 days), CSV export. Default OFF to respect privacy by default. This gives frontline users immediate, self-serve evidence for “accepted by recipient server vs. blocked/quarantined later.” Connect: Deliverability events Add webhooks to enable automation: EmailDeliveryAccepted (fire when recipient MX returns 250) EmailDeliveryFailed (fire when explicit rejection or retries exhaust) Payload includes minimal, masked metadata (e.g., smtpCode, timestamp, hashed MX) so customers can trigger automatic fallbacks (e.g., SMS notification, re-send from alternate channel, or internal admin review) without opening Support cases. Security & Compliance Metadata-only (no email content or PII beyond standard recipient identifiers). Feature is opt-in (admin-controlled) and fully audited (access and events). Data minimization: masked MX/message details; configurable, short retention. Behavior is backward-compatible: when disabled, nothing new is exposed. Acceptance Criteria (examples) When the recipient server returns 250, Envelope History shows accepted=true with timestamp; if enabled, an EmailDeliveryAccepted event is emitted. When delivery is rejected or retries exhaust, UI shows non-250 details (masked) and an EmailDeliveryFailed event is emitted. CSV export reflects exactly the on-screen metadata fields. With the feature disabled, neither UI elements nor events appear. Impact / PriorityP1. Dramatically reduces Support cases and MTTR, removes compliance friction, enables at-scale automation for exception handling, and protects customer NPS as send volumes grow. This solution focuses on what operators need most: clear, self-serve deliverability evidence inside the envelope and machine-readable webhooks to close the loop automatically. 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
I would like to submit a suggestion for improvement regarding envelope notifications.Currently, the prefix “Completed with DocuSign” is automatically added at the beginning of the email subject line.Would it be possible to make this prefix optional or configurable?This would help improve the overall user experience.Thank you in advance for considering this suggestion.
Our Workflow Builder (formerly Maestro) workflows come back to us after the customer signed and go through several backroom departments. We would like the ability to add comments to the document that are not seen by the customer that signed and do not show up on the Certificate Summary.
In an eWorkflow Builder (formerly Maestro) workflow, after sending an e-signature template for signature, no further steps can be performed until the sent envelope is closed. Is there a way to change this? Specifically, to execute the further steps upon sending the envelope instead of only after it's closed?





Docusign Community
Code of ConductAlready have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.