Skip to main content

    Filter by Idea status

    Filter by category

    1045 Ideas

    Eric.NobleNewcomer

    Allow Dynamics Administrators to Control Which Dynamics 365 Entities Display DocuSign Log In/Log Out CommandsIdea Submitted

    Today, DocuSign for Dynamics 365 allows administrators to configure which entities are enabled for DocuSign actions such as Sign, Send with DocuSign, and Bulk Send with DocuSign. However, the DocuSign Log In/Log Out ribbon commands (which I believe came as part of the move to OAuth) appear on entities that are not enabled for DocuSign use.We would like an enhancement that gives administrators explicit control over where the Log In/Log Out commands are displayed, ideally leveraging the existing entity configuration experience within DocuSign Admin.Suggested approaches:Only display Log In/Log Out commands on entities that are enabled for DocuSign integration (e.g. Sign, Send, Bulk Send). Alternatively, add a configurable setting per entity that controls Log In/Log Out visibility, similar to existing DocuSign command configuration options.Business Value I would assume most organizations use DocuSign with only a subset of Dynamics 365 entities. Displaying Log In/Log Out commands across unrelated entities:Creates unnecessary ribbon clutter. Confuses users who will never use DocuSign. Introduces DocuSign-related processing on forms that have no DocuSign business purpose. Limits administrators' ability to tailor the user experience to their business processes.Providing entity-level control would improve usability, reduce user confusion, and better align the DocuSign experience with how customers already configure entity-specific functionality in Dynamics 365.Expected Outcome Administrators should be able to determine exactly which entities expose DocuSign authentication commands, resulting in a cleaner and more relevant Dynamics 365 experience for end users.

    szucsgNewcomer

    Swisscom QES envelope to void automatically if validation attempt fails 3 timesIdea Submitted

    For a little context: recently I had a customer try to set up a QES passkey with our Swisscom QES service, so I have sent an envelope with a simple document, but the customer failed 3-4 times during verification due to being able to pass a verification test. Checked envelope history but there was no information about it, so contacted support to get some information through Swisscom.Now I received some instructions about “what can fail”, but could not get specific details about customer’s attempts and potential failures - this is not the best either, but I can understand QES validation is strict, thus, the verification service provider does not disclose details to avoid fraud.Nevertheless, support also pointed out that after 3 failed verification attempts, the envelope SHOULD be voided since no further attempts will be successful - quoting support:“The envelope will not be voided automatically after 3 attempts. It will only not allow the signer to use the QES verification anymore. She could initiate further attempts after the third attemp but it will just fail.”Nothing did signal that to the user, and to me as the sender of the envelope - that should be changed, there should either be a warning to the user, and to the sender and it should also have some record in the envelope history, or optimally, the envelope should automatically be voided in that case.

    Include Decline Reason in Email Notifications Sent to CC RecipientsIdea Submitted

    Hello,I would like to suggest an enhancement regarding envelope decline notifications.Currently, when a signer declines an envelope and provides a reason, the decline reason is included in the email notification sent to the sender. However, recipients who are included in the workflow as CC recipients only receive a notification that the envelope was declined and do not receive the actual reason entered by the signer.This can create challenges in organizations that use a shared or service account as the sender (for example, through an integration), while business users and stakeholders are added as CC recipients to stay informed about the envelope status.Suggested enhancement: Provide an account-level or envelope-level option that allows the decline reason entered by the signer to be included in the decline notification emails sent to CC recipients.Benefits:Improved visibility for all stakeholders involved in the signing process. Reduced need for manual follow-up with the sender. Better support for integrated and automated DocuSign environments that use service accounts. Faster resolution of issues that caused the signer to decline the document.Ideally, administrators could enable or disable this behavior according to their organization's security and privacy requirements.Thank you for considering this enhancement. I believe it would improve transparency and communication throughout the signing workflow. **information removed due to PII**