Skip to main content

    Filter by Idea status

    Filter by category

    1017 Ideas

    DocuSign Company Field Auto FillingIdea Submitted

     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

    Scott.Nieman
    Troubleshooter
    Scott.NiemanTroubleshooter

    Roll up recipient status to the envelope summary levelExisting Functionality

    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. 

    Email Deliverability in Envelope History + Webhooks for SMTP AcceptanceIdea Submitted

    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