Skip to main content

    Filter by Idea status

    Filter by category

    990 Ideas

    Lara MooreNewcomer

    Enable Send Later (Scheduled Sending) when using Shared Access with Send permissionIdea Submitted

    Currently, users with Shared Access and Send permission can create and send envelopes on behalf of another user, but they cannot use the Send Later (Scheduled Sending) feature. This limitation requires users to either send envelopes immediately or log in directly as the shared user to schedule delivery.Many organizations use Shared Access for centralized mailboxes (such as HR, Benefits, Payroll, or Legal) so employees can send documents from a shared account while maintaining their own credentials and audit trail.A common use case is preparing onboarding or HR documents in advance and scheduling them to be sent at a specific date and time. Although Scheduled Sending is available when working in the account directly, it is not available when acting through Shared Access, forcing organizations to choose between security best practices and scheduling functionality.Requested enhancement:Allow users with Shared Access and Send permission to use Send Later (Scheduled Sending) for envelopes they create while acting on behalf of the shared user.Business benefits:Supports secure use of Shared Access without requiring users to log in as shared accounts. Enables HR, Payroll, Benefits, Legal, and other administrative teams to prepare and schedule communications in advance. Improves workflow efficiency by eliminating the need to manually send time-sensitive envelopes. Provides feature parity between direct account access and Shared Access for users with Send permission.This enhancement would make Shared Access a more complete solution for organizations that rely on centralized sending accounts while following security and governance best practices.

    Feature Request – Default Copy Recipient at Account LevelIdea Submitted

    Hi team,We would like to submit a feature request, as our research indicates that this functionality is currently not supported in DocuSign eSignature.Feature descriptionThe requested functionality is to have a default recipient of a copy automatically added to every envelope created by specific groups of users. To clarify, this would not be a default recipient configured on individual templates, but rather an account-level configuration that automatically adds the designated copy recipient regardless of whether the sender uses a predefined template or creates an envelope from scratch.Ideally, this would be configurable so that different groups of users could have different default copy recipients. For example, most users could have one designated mailbox automatically added, while HR or other departments could have different mailboxes configured.Additionally, users should have the ability to remove the automatically added copy recipient for individual envelopes whenever necessary.Business use caseThe main objective of this feature is to ensure that fully executed agreements are automatically copied to the appropriate shared mailbox, providing centralized visibility, governance, and document retention without relying on users to manually add the recipient each time they send an envelope.Today, users can easily forget to include the appropriate mailbox, which may result in executed agreements not being centrally stored or visible to the teams responsible for contract management. An account-level configuration would significantly reduce this risk while still allowing flexibility when exceptions are needed.We explored the suggested workaround of using eSignature templates with predefined copy recipients. However, this approach does not fully meet our business needs. It introduces additional steps for users when sending documents, removes the ability to use the drag-and-drop sending experience if template usage is enforced, and would require users to always select the appropriate template before sending.In addition, we would prefer not to make template usage mandatory for users who do not otherwise need templates as part of their workflow. We are looking for a solution that works seamlessly regardless of how an envelope is created, while preserving users' existing sending experience.Workflows and users that would benefitThis functionality would benefit multiple departments across our organization that use DocuSign eSignature. Different business units require different shared mailboxes to receive copies of executed agreements (for example, Legal, HR, or other operational teams), making group-based configuration important.The feature should apply regardless of how an envelope is created, whether users send documents from templates or create envelopes from scratch, and should support organizations with multiple teams that have different document management requirements.Could you please let us know whether this feature would be feasible to implement? If so, is there any estimated timeline for when it could potentially become available?Please let us know if you need any additional information from our side. Thank you! 

    PslimNew Voice

    Agreement Manager - Use Folder-Level Path as Categorization Metadata on Bulk UploadIdea Submitted

    When bulk uploading agreements into Agreement Manager, categorization currently relies on AI content analysis after ingest, or manual assignment to agreement types/categories/sets. There's no way to leverage the folder structure of the files being uploaded (e.g., from a mapped drive or cloud storage) as a source of categorization metadata.Many organizations already store historical agreements in a meaningful folder hierarchy, such as:/Sales/MSAs/2026//Procurement/Vendor Agreements/2026/Today, this structure is lost on upload — every file lands in Agreement Manager as an individual record, categorized only by what the AI infers from the document content, or by tags applied manually afterward.Request: When uploading a folder (or nested folders) of agreements, allow the folder path to be captured and mapped to categorization fields, for example:Auto-populate or suggest an agreement type, category, department, or custom field based on the folder name(s) in the path Let admins define a mapping between folder structure and metadata fields before or during upload (e.g., top-level folder → Department, second-level folder → Agreement Type) Preserve the original folder path as a searchable attribute on the agreement record, even if the user doesn't set up a mappingWhy it matters: Migrating agreements from network drives, SharePoint, or other DMS tools into Agreement Manager means re-doing categorization work that already exists in the folder structure. Using folder-level information would speed up migration, reduce manual tagging, and give AI categorization a stronger starting signal instead of relying on content inference alone.

    backofficeNewcomer

    Improving workflow for compelling applicants to complete the signing process (gateway leading applicants from the ID verification step to signing relevant documents)Idea Submitted

    After the recipient processes the identification step during the E-signature process, recipients are asked to sign the fields they're assigned. However, if recipients did not complete the process by clicking the correct buttons such as Sign or Complete, the envelope will not be considered completed and shall remain in a limbo as pending which implies unnecessary follow up frictions with recipients.This is so because in DocuSign, recipients have the option to skip their signing at a later time. They can also leave their signature on the envelope, and if they do not properly complete the signing, the signature will be saved but will not be completed.Our past experience tells that clearing the ID verification to signing relevant paperwork is very often confusing or not properly guided within your current workflow display. We suffer ongoing failures from recipients failing to complete the signature process after having been identified.  They think they have completed the process but the actual processing status at DocuSign is recorded as signature pending. We understand the purpose of expecting clients to push a button to confirm submission after they have signed the forms. However, this extra layer of requirement for the final submission should be smoothen by clearly disclosing to recipients the need to push the “Complete” button.We think that there is a lack of specific guidance needed while recipients are processing the entire signature process. This could be perhaps quite easily upgraded by disclosing:Step 1- ID verificationStep 2 - SignatureStep 3 - Confirming submission by clicking the “Complete” button. Recipients that would have signed documents BUT forgot to also push the “Complete” button should be warned about the resulting pending status of their submissions, prompting recipients to Complete it if they want to move ahead.It would be great if you'd take this into account for quality improvements at your end. Thank you

    Malik PressNewcomer

    Docusign Part 11 Signing Reason AssignmentIdea Submitted

    Current ChallengeWhen signing Part 11 envelopes, signers must select a "Signing Reason" for every signature applied. Currently, the dropdown menu to select a Signing Reason displays all Signing Reasons defined for the selected system language. By default, Docusign Part 11 provides three Signing Reasons (Author, Reviewed, Approve). Through the "Signing Resource File" of a specific Brand, an Admin can modify these or add custom reasons. However, for GMP documents, there is a fixed hierarchy of required signatures: 1. Author signatures, then 2. Reviewer signatures, finally 3. Approver signatures (Approver signatures are mandatory for every GMP document; Necessity of Author/Reviewer signatures vary by GMP document). Consequently, when we create a Part 11 envelope, the selection and order of signers are based on these requirements. Each signer is assigned a fixed role (Author, Reviewer, or Approver), which dictates exactly which Signing Reason they must select. Currently, we assign these roles visually at document creation via a signature table within the document itself (columns: Role, Name/Function, Signature). We explicitly enter "Author," "Reviewer," or "Approver" in the role column of each signer row. Signers are trained to check this column and then manually select the matching Signing Reason in Docusign. Pain PointsUnfortunately, deviations frequently occur. Despite training and support materials, signers often select a Signing Reason that does not match their assigned role. When this happens, the entire Part 11 envelope must be voided, re-created, and re-sent for signatures. Additionally, I noticed that when adding custom Signing Reasons via the Signing Resource File, they must be added manually for all languages. Otherwise, the custom reasons do not appear if a signer uses a different system language. Proposed Solutions (User Stories)To improve the "First-Time-Right" rate for signers and reduce the administrative burden of managing Signing Reasons, I have defined the following requirements: High PriorityHP1: As an Admin, I want to create, update, and delete Signing Reasons in a dedicated Admin Setting Section, so that they are available for all Part 11 envelopes regardless of the selected Brand.HP2: As an Admin, I want to define a Default Label for each Signing Reason, so that the reason is displayed to all signers even if a specific translation is missing.HP3: As an Admin, I want to define labels for all available system languages for each Signing Reason, so that they appear correctly in the signer's selected system language.HP4: As a Sender, I want to select/restrict the specific Signing Reasons available to a signer when creating a Part 11 envelope, ensuring the signer cannot accidentally select an incorrect reason. Low PriorityLP1: As an Admin, I want to create, update, and delete "Signing Roles" in a dedicated Admin Setting Section.LP2: As an Admin, I want to assign one or more Signing Reasons to a specific Signing Role.LP3 (Alternative to HP4): As a Sender, I want to assign a "Signing Role" to a signer when creating an envelope. This would restrict the dropdown menu to only show the Signing Reasons assigned to that role, ensuring the signer cannot accidentally select an incorrect reason.