The Integration Key (also called a Client ID) identifies the Vault CRM integration to Docusign. Docusign admin users create this once in a demo (development) account, test it, then promote the same key to a production account.

To create the Integration Key:

1. Log in to your Docusign demo/developer account at https://apps-d.docusign.com.
2. Navigate to Admin > Account > Apps and Keys.
3. Select Add App and Integration Key.
4. Enter an App Name. Veeva recommends a name that identifies this as the Vault CRM integration (for example, EM or Vault CRM Docusign Integration).
5. Select Service Integration (JSON Web Token Grant) for the Authentication Type. This integration authenticates server-to-server with no interactive login, using JWT and Admin consent for impersonation.
6. Select Private custom integration for the Integration Type. Docusign generates the Integration Key (a GUID) automatically. The new app displays in the Apps and Integration Keys list with Environment = Development and a Go Live Status badge reading “Ready to Submit / Promote to production.” This confirms the key was created correctly.
7. Copy the Integration Key. This is used throughout the remaining configuration steps.

The integration signs its requests to Docusign using an RSA key pair: a private key, which stays with Vault CRM and must be kept secret, and a public key, which is provided to Docusign to verify requests.

Veeva Vault security policy requires private keys in the PKCS#8 format.

These instructions use OpenSSL to create the keys, a free command line tool. You do not need to understand cryptography to follow them, you will run a handful of commands, then paste the results into two places. The whole process takes about ten minutes.

Verify OpenSSL is Installed

To verify OpenSSL is installed, open a terminal window and run the following command:

openssl version

If OpenSSL is installed, a version number displays. For example:

OpenSSL 3.0.13 30 Jan 2024

If a “command not found” or “not recognized” message displays, install OpenSSL:

• Windows - Install Git for Windows, which includes OpenSSL. After installing, open the Git Bash application and run the commands below
• macOS - OpenSSL is already installed. Open the Terminal application by navigating to Applications > Utilities
• Linux - OpenSSL is installed on most distributions. If not, install the openssl package using the package manager.

Create a Working Folder

To create a working folder, run the following commands using the terminal window:

mkdir docusign-keys

cd docusign-keys

This creates a folder for the two key files to keep them together and make it easier to delete afterwards. Everything following happens from this folder.

Generate the Private Key

Run the following command to generate the private key. The private key is created in PKCS#8 format:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out docusign_private_pkcs8.pem

Use 2048 bits. This matches the key size Docusign generates. A larger key size might be rejected when uploading.

While the key is generated, OpenSSL prints a long line of dots and plus signs. This is normal progress output, not an error.

When the command finishes, a file named docusign_private_pkcs8.pem exists in the folder.

Generate the Public Key

To generate the public key, run the following commands using the terminal window:

openssl rsa -in docusign_private_pkcs8.pem -pubout -out docusign_public.pem

The public key is derived from the private key previously created. This command reads the first file and writes the second. OpenSSL confirms with a short message:

writing RSA key

Verify the Key Files

The following keys are generated:

File	Where Used
docusign_private_pkcs8.pem	Vault CRM. Secret; treat it like a production password. Do not send it by email or chat, do not store it in a shared drive or a ticket, and do not keep a copy after the integration is confirmed working. If the private key is ever exposed, generate a new key pair and remove the old one from Docusign.
docusign_public.pem	Docusign. Not secret; safe to email or paste anywhere.

Run the following verification commands before uploading. They take a few seconds and catch the most common mistakes.

1. Check the private key is PKCS#8. Display the first line of the private key file (Git Bash, macOS, or Linux):

   head -1 docusign_private_pkcs8.pem

   The result must be exactly:

   -----BEGIN PRIVATE KEY-----

   If it is BEGIN RSA PRIVATE KEY, the file is in PKCS#1 format. Delete it and repeat Section 2.3, verifying the command was entered correctly.

2. Verify the keys match. This command produces a fingerprint of the public key as derived from the private key, then a fingerprint of the public key file itself:

   openssl pkey -in docusign_private_pkcs8.pem -pubout -outform DER | openssl dgst -sha256

   openssl pkey -pubin -in docusign_public.pem -outform DER | openssl dgst -sha256

   The two lines of output must be identical, for example:

   SHA2-256(stdin)= 5a31f0e1ba58e9e72a6b904b6b8cdf61...

   SHA2-256(stdin)= 5a31f0e1ba58e9e72a6b904b6b8cdf61...

   If they differ, the two files are not a matching pair. Delete both and generate a new key pair.

Upload the Public Key to Docusign

To upload the public key:

1. Open the public key file in a plain text editor, for example Notepad on Windows or TextEdit on macOS. Do not use Word, which can alter the contents.
2. Select and copy the entire contents of the file, including the BEGIN PUBLIC KEY and END PUBLIC KEY lines and all line breaks.
3. Navigate to Admin > Apps and Keys in Docusign.
4. Select the Integration Key created previously, then select Actions > Edit.
5. Select + UPLOAD RSA in the Service Integration section.
6. Paste the public key into the text area.
7. Select Save. Docusign displays a keypair ID. This confirms the upload succeeded.

Adding a key pair does not remove existing ones. Docusign accepts requests signed with any available key pairs. Do not remove an old key pair until the integration is confirmed as working with the new key pair.

Add the Private Key to Vault CRM

To add the private key to Vault CRM:

1. Open the private key file in the same plain text editor.
2. Select and copy the entire contents, including the BEGIN PRIVATE KEY and END PRIVATE KEY lines and all line breaks.
3. Log into Vault CRM and navigate to Admin > Configuration > Application Configurations > Docusign Integration > Edit > RSA Private Key.
4. Paste the private key into the RSA Private Key field.

   The key must retain its original line breaks. Pasting it as one line is the most common cause of failure, and usually produces an error mentioning PEM. If you are unsure, paste the key into a plain text editor first to confirm it still displays as multiple lines.

5. Select Save. The remaining connection fields are entered together in a later step.

Retain the local key files until the full connection is confirmed working, then delete both files from your computer. The private key is stored in Vault CRM and the public key is stored in Docusign, so there is no reason to keep local copies once they are verified.

To remove the local copies, run the following commands:

cd ..

rm -rf docusign-keys

Troubleshooting

• A “command not found” or “openssl is not recognized” error
• OpenSSL is not installed, or you are not running the commands in the right window. On Windows, these commands must be run in Git Bash, not Command Prompt or PowerShell
• The private key file begins with BEGIN RSA PRIVATE KEY
• The file is PKCS#1, not PKCS#8. Repeat Section 2.3, or see the appendix below if you need to convert an existing key
• An error mentioning PEM when the integration runs
• The key was almost certainly pasted as a single line, or is missing its BEGIN or END line. Repeat Section 2.7 and confirm the line breaks are preserved
• Docusign rejects the public key
• Confirm you copied the public key file and not the private key, that it begins with BEGIN PUBLIC KEY, and that no characters were lost at the start or end.
• Authentication fails after uploading
• Run the fingerprint check in Section 2.5 again. If the fingerprints do not match, the key in Docusign is not the partner of the key in Vault CRM.

Converting an Existing Key

If Docusign already generated a key pair and the private key is saved, you can convert it to PKCS#8. The converted key is the same key in a different format. The public key already held by Docusign remains valid and does not need to be replaced.

To convert the key:

1. Save the existing private key to a file, for example docusign_private_pkcs1.pem, including the BEGIN and END lines.
2. Run the following command:

   openssl pkcs8 -topk8 -nocrypt -in docusign_private_pkcs1.pem -out docusign_private_pkcs8.pem

   Confirm the result is PKCS#8 by entering the following command:

   head -1 docusign_private_pkcs8.pem

   The result should be:

   -----BEGIN PRIVATE KEY-----

3. Load the converted key into Vault CRM. See Add the Private Key to Vault CRM. Generating the matching public key and uploading the public key to Docusign are not required because Docusign already holds the matching public key.

The Vault CRM Docusign integration sends emails on behalf of an Events Management user to each contract recipient. Before Docusign can send an email, those users' accounts must explicitly authorize the Docusign integration to act on their behalf. This authorization is called consent and is a requirement of Docusign, not Vault CRM.

Docusign offers two ways to grant this consent. Select the method that best fits your organization.

	Individual Consent	Administrator Consent
Best for	Smaller teams, or organizations without Docusign Organization Administration, OR Docusign emails are sent on behalf of the integration User and not each EM user.	Organizations already using Docusign Organization Administration
Who takes action	Each individual user who will send contracts	One Docusign organization administrator
Covers new users automatically?	No, each new user must repeat the steps below	Yes, all users on the verified domain are covered

Before you begin, you will need:

• A Docusign account and password for the person who will complete the steps below
• The Integration Key (Client ID)
• A Redirect URI for the integration (Docusign > Apps and Keys > Edit on your Integration Key > Additional settings > Redirect URIs). The URI can be any URL; it is only used to redirect the user once consent is confirmed.

Signing in to Docusign

To sign into Docusign:

1. Open a web browser and navigate to one of the following:
   • Production: https://account.docusign.com
   • Sandbox: https://account-d.docusign.com
2. Sign in with the user requiring consent

Option 1 - Individual Consent

Individual consent is granted by a specific Docusign user logging in and accepting a permissions request.

1. Build your consent URL. The user opens this URL in a browser to grant consent:
   • Use the Integration Key (Client ID) and Redirect URI you copied earlier (see “Before you begin” above)
   • Use the server address that matches the environment: account-d.docusign.com for Demo/Sandbox, or account.docusign.com for Production
2. Assemble the URL using the pattern below, replacing each bracketed placeholder with your own values. Do not leave the brackets in the final URL.

   https://[SERVER]/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=[INTEGRATION KEY]&redirect_uri=[REDIRECT_URI]

Example (production):

https://account.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=1a2b3c4d-5e6f-7890-abcd-ef1234567890&redirect_uri=https://www.example.com/consent-confirmed

3. Sign in to Docusign as the user that is providing consent.
4. Open a new browser tab and paste the completed URL into the address bar.
5. Select Enter. The Docusign sign in screen displays.
6. Enter the email address of the user granting consent.
7. Select Continue.
8. Enter the user's password.
9. Select Log In. A screen displays the name of the application requesting access and the requested permissions for Signature and Impersonation.
10. Review the information displays, then select Accept. The browser redirects to the configured URL.

Option 2 - Administrator Consent

Use this method if your organization uses Docusign Organization Administration. This method requires one setup process performed once by a Docusign administrator, after which all current and future users on your verified domain are automatically covered.

To administer consent:

1. Ensure Docusign Organization Administration is enabled and the domain associated with your user's email address has been claimed by your organization via the Docusign Claim a Domain process.
2. Ensure a Docusign user with the Administrator permission profile exists.
3. Follow Docusign's steps to claim a domain. If you have already claimed a domain, continue to the next step.
4. Build the consent URL a user opens in a browser to grant consent:
   • Use the Integration Key (Client ID) and Redirect URI copied earlier.
   • Use the server address that matches the environment:
     • account-d.docusign.com for Demo/Sandbox
     • account.docusign.com for Production
5. Assemble the URL using the pattern below, replacing each bracketed placeholder with your own values. Do not leave the brackets in the final URL:

   https://[SERVER]/oauth/auth?response_type=code&scope=openid&client_id=[INTEGRATION KEY]&redirect_uri=[REDIRECT_URI]&admin_consent_scope=signature%20impersonation

   Example (production):

   https://account.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=1a2b3c4d-5e6f-7890-abcd-ef1234567890&redirect_uri=https://www.example.com/consent-confirmed&admin_consent_scope=signature%20impersonation

To log in and grant consent:

1. Log in to Docusign as the user providing consent.
2. Open a new browser tab and paste the completed consent URL into the address bar.
3. Select Enter. The Docusign login screen displays.
4. Enter the email address of the user granting consent.
5. Select Continue.
6. Enter the user's password.
7. Select Log In. A screen displays the name of the application requesting access, along with the permissions it's asking for, you should see signature and impersonation listed.
8. Review this screen, then select Accept. The browser redirects to the configured URL.

Test in the demo environment

Before promoting to production, complete entering connection details in Vault CRM using your demo credentials, and use the Test Connection action on the Vault CRM Docusign Integration page to confirm the connection succeeds. Do not proceed to production promotion until the demo connection test passes.

Promote to production

This step creates new credentials.

Promoting to production does not copy your demo secret key, RSA key pair, or redirect URI forward. You will generate a new RSA key pair and a new secret key for the production app, and re-enter all connection details in Vault CRM's production environment. The Integration Key (GUID) itself stays the same across both environments.

To promote to production:

1. From the same Apps and Keys page in your demo account, locate your app and select Actions > Promote to production. This option displays once the Go Live Status is “Ready to Submit.”
2. Follow Docusign's Go-Live prompts to submit the app for production.
3. Log in to your production Docusign account at https://apps.docusign.com once promoted.
4. Locate the same app under Admin > Apps and Keys.
5. Generate a new PKCS#8 key pair and upload it for the production app. These are separate credentials from your demo environment and are not shared.
6. Grant consent for the production environment.
7. Enter the connection details in Vault CRM's production environment using the new production credentials (see the next section).

Docusign generates the HMAC Secret Key for you. Unlike the RSA key pair, you do not create it yourself and there is nothing to upload back to Docusign. The HMAC Secret Key allows Vault CRM confirm a webhook notification about envelope status genuinely came from Docusign and was not altered in transit.

Docusign displays a note on the Connect Keys tab stating that HMAC settings apply to Account-Level Configurations. You do not need to create a Connect configuration for this integration, and the Configurations tab will remain empty. Vault CRM registers the webhook on each envelope as it is created, and the key generated below signs those messages.

To generate the HMAC Secret Key:

1. Log into Docusign
2. Select Admin > Connect (Webhooks).
3. Select the Connect Keys tab.
4. Select Add Secret Key. Docusign generates the key immediately and adds it to the Keys list.
5. Select the copy icon next to the key to copy the full value. The list displays only a truncated preview; manually copying from the screen will produce an incomplete key.
6. Paste the value into the HMAC Secret Key field in Vault CRM, as indicated below.

To enter the connection details in Vault CRM's production environment using the new production credentials:

1. Log into Vault CRM.
2. Navigate to Admin > Configuration > Events Management > Docusign Integration.
3. Select Edit next to Connection Management.
4. Enter the following values using the credentials generated previously and the HMAC Secret Key.

Vault CRM Field	Where to find it in Docusign / what to enter
Integration Key	The GUID shown on the Apps and Keys page for your app (Section 1).
User ID	Admin > My Account Information, field labeled “User ID”, a GUID unique to your Docusign user.
Account ID	Admin > My Account Information, field labeled “API Account ID.”
Server Region	Your account's regional code (for example na1 or eu). Required for production connections; leave blank for a demo/sandbox connection, where Docusign uses “demo” automatically.
Sandbox	Check this box for a demo/development connection. Leave unchecked for production.
RSA Private Key	Already entered in Section 2.7. Shown here for reference, paste the private key generated in Section 2, including the BEGIN/END lines, if not already saved.
HMAC Secret Key	A secret value used to verify webhook payloads. Generated in Docusign under Admin > Connect (Webhooks) > Connect Keys > Add Secret Key, see above. Use the copy icon to capture the full value.

Testing the Connection

Select Test Connection from the Connection Management section to allow Vault CRM to validate your JWT token generation, RSA key, Integration Key status, User ID, Account ID, and consent status in a single check. A green “Credentials are valid” alert confirms the connection is working. If you see a “Connection Test: Errors Encountered” pop-up instead, review each listed error, the most common cause is that consent has not yet been granted or a credential was copied with extra whitespace.

Once the test passes, delete the local key files; they are no longer needed.

The contract document itself, its layout, text, and data population, is built and maintained entirely in Vault CRM. Docusign never stores a separate copy of that layout. Vault CRM generates a PDF for each contract and sends it to Docusign at the moment a signature request goes out.

You do not need to build or maintain the contract’s document content in Docusign. However, you do need to configure Recipient Roles in the Docusign Template itself, and share that template with the users who will send contracts, see below. Both are required steps, not optional ones.

Recipient roles must be configured in Docusign and match Vault CRM exactly

Each Docusign Template referenced by an EM Contract Template (via that record's Docusign Template ID field) must have its Recipient Roles defined in Docusign, and each role's API name must exactly match the corresponding Signer Role picklist value in Vault CRM (signer_role__v, for example, speaker__v).

This match is required because the integration targets tabs to recipients using the role name in the token, for example, [role:speaker__v], and Docusign uses its own Recipient Role configuration to resolve which signer that role refers to on the envelope. If a role name in Docusign does not match the Vault CRM picklist value exactly, the integration cannot place that signer's fields correctly and the send will fail or route fields to the wrong signer.

1. In Docusign, open the Templates area and select the Docusign Template referenced by this EM Contract Template's Docusign Template ID.
2. Under the Docusign Template's Add recipient configuration, define a Recipient Role for each signer type this contract type will use.
3. Set each role's name to exactly match the corresponding Vault CRM signer_role__v picklist API name, matching is case-sensitive.
4. The Name and Email fields should be left blank.
5. Select Needs to Sign.
6. For Carbon Copy recipients, create 5 roles. The Role name must be carbon_copy_1__v,carbon_copy_2__v, etc.. and the signing action should be set to Receives a Copy.
7. Repeat for every Docusign Template used by your EM Contract Templates. If one Docusign Template is reused across multiple EM Contract Templates, its roles only need to be configured once.

If the Roles do not Match

A mismatch between a Docusign Recipient Role and the Vault CRM signer_role__v value is a common cause of signature requests failing to send or fields appearing on the wrong signer’s copy. If you add a new Signer Role value in Vault CRM, you must also add the matching Recipient Role in every Docusign Template that will use it.

What to enter in each field when adding a role

Field	What to enter
Field	What to enter
Role	For signer - The exact signer_role__v API name from Vault CRM (for example, speaker__v). Required.   For CC:   carbon_copy_1__v carbon_copy_2__v carbon_copy_3__v carbon_copy_4__v   carbon_copy_5__v
Name	Leave blank. Docusign templates supply recipient name and email at the moment the envelope is created, not in the template itself, Vault CRM sends this value from the Contract Partner record for every send.
Email	Leave blank, for the same reason as Name.
Signing action (Signer)	Signer - Set to ‘Needs to Sign’ Carbon Copy - Set to ‘Receives a Copy’
Customize	Leave unconfigured. This integration does not use per-recipient customization options such as custom notification text or ID verification.

Share the template with the users who will send contracts

A Docusign Template is visible only to the user who owns it until it is shared. Because the integration creates each envelope as the sending Vault CRM user, a template that has not been shared with that user cannot be found on their behalf, and the send fails even though the template exists and its Recipient Roles are configured correctly.

1. Log into Docusign.
2. Select Templates.
3. Locate the template referenced by this EM Contract Template’s Docusign Template ID.
4. Select Share with Users from the All Actions menu. Do not use Share to Folders in that same menu. It controls which folders the template appears in, not the per-user access this integration requires.
5. Add every Docusign user who will manage or send contracts from this template in Vault CRM. At minimum this is every user who has a value in docusign_user_id__v on their Vault CRM User record. If signature request emails are sent from the integration user rather than from the Vault CRM user who selected Send for Signature, share the template with the integration user as well.
6. Repeat these steps for every Docusign Template referenced by an EM Contract Template.

If your Docusign account supports sharing with groups, share the template with a group that contains your sending users rather than naming each user individually. New senders then inherit access as they are added to the group, with no template change needed when staff change.

Docusign sends every notification email a signer receives, the initial signature request, reminders, decline notices, void notices, and the completed-document email. Vault CRM does not compose these emails; it sends the contract data and Vault CRM has no control over the wording unless you use merge fields as described below.

Two different records are used:

• EM Contract Template - The record in Vault CRM that defines the contract document, and stores the docusign_template_id__v field.
• Docusign Template - The corresponding template that lives in your Docusign account, identified by that same ID. This is where the email Subject and Message are actually configured.

The docusign_template_id__v field on the EM Contract Template record is only a pointer, it tells Docusign which Docusign Template to use when the envelope is created. That Docusign Template's own “Message to All Recipients” settings, Subject and Email Message, are what Docusign actually sends. To change the wording a signer receives, you edit the Docusign Template in Docusign, not the EM Contract Template in Vault CRM.

Using Merge Fields to Personalize

Docusign's merge field support for templates is limited, and it is easy to overstate what's available, the Salesforce-integrated version of Docusign supports a much broader merge field system that does not apply here. This integration uses the eSignature REST API directly, not the Salesforce package, so only the native eSignature merge field behavior applies.

• Subject line - Supports Recipient Name and Recipient Email Address as merge fields, inserted via the merge-field icon after adding a recipient role to the Docusign Template.
• Message body - The Docusign Template editor has no merge field support for the body. Docusign has an API-level mechanism for per-recipient body text, the emailBody property on a recipient's RecipientEmailNotification object, sent at envelope creation, but this is additional text prepended to the message, not a template merge field, and it is not part of how this integration sends data today (the current spec has Vault CRM leave email content entirely to the Docusign Template). Until that changes, treat the body as fixed, static text configured once in the Docusign Template, the same for every recipient on every contract.

The Email Subject field is limited to 100 characters, including the expanded value of any merge field. If your subject plus the longest expected merge field value could exceed 100 characters, shorten the static text.

Branding lets you apply your organization's logo, colors, and messaging to what speakers and signers see throughout the Docusign experience, the signing pages, every notification email, and where they land afterward. This entire section is optional; if skipped, Docusign uses its default appearance and behavior throughout.

Basic Branding (Logo and Colors)

1. Log into Docusign.
2. Select Admin > Brands. If you see an option to Add Brand, your plan supports custom branding.
3. Follow Docusign's prompts to upload a logo and set colors.
   • If Add Brand is unavailable or grayed out, your current Docusign plan does not include custom branding. Contact your Docusign account representative to discuss upgrading, or skip this section, the integration functions normally without it.
   • Once a brand is created, copy its Brand ID and enter it into the docusign_brand_id__v field on the corresponding contract record in Vault CRM. This field is optional, leaving it blank uses your account's default brand.

Advanced Configuration

Within a brand, Docusign offers four additional configuration areas, grouped under Advanced Configuration:

• Destination URLs, controls where the signer lands after they finish signing, decline, or their session otherwise ends. By default Docusign shows its own confirmation screen; this lets you redirect to a page of your choosing instead.
• Header and Footer Links, controls the Contact Us / Terms of Use / Privacy / Support link URLs that appear at the bottom of every email this brand sends. This is a simple link-editing screen, separate from the Resource Files below.
• Select Brand Languages, controls which languages this brand supports, for accounts sending to signers across multiple locales
• Resource Files (described below)

Email Resource Files (Advanced)

Resource files let you customize the wording Docusign uses across its system emails, beyond what any individual template controls. This is an advanced, XML-based configuration, Docusign states it should only be used by someone experienced working directly in XML, and it requires Advanced Branding to be enabled on the account; contact your Docusign account representative if the option isn't available.

To use resource files:

1. Select a language and resource type (Email, Signing, or Captive Signing), then Download Master to get Docusign's current default XML.
2. Edit the XML directly.
3. Upload your modified version. Only the differences between your version and Docusign's master are saved.

To restore defaults, download the default-language master again and re-upload it to the same slot.

Constraints to know before editing:

• Only one custom file per type is allowed per account, and it must include every language you want to customize; you can't upload separate files per language
• Some system email wording, specifically the voided, declined, and completed notifications, cannot be edited through this file at all. Docusign restricts these intentionally, to prevent a customization from misrepresenting an envelope's legal status.

Available Merge Tokens

Found by searching the downloaded master file for [[Data:, the tokens below are confirmed by Docusign's own documentation and support staff:

Token	What it inserts
[[Data:SenderName]]	The sending user's name
[[Data:SenderEmail]]	The sending user's email address
[[Data:EnvelopeID]]	The envelope's unique ID
[[Data:EnvelopeExpirationDate]]	The envelope's expiration date
[[Data:VoidReason]]	The reason entered when an envelope was voided (blank if not applicable)
Recipient name / email	Same as available in template merge fields
Envelope Custom Fields	Usable here as well

Three Levels of Email Control

Docusign email content is controlled at three separate levels, each with a different scope, a different editing method, and a different blast radius when changed. Getting these confused is a common mistake, editing the wrong level either doesn't produce the change you wanted, or produces a much bigger change than intended:

• Per-Template - Controls the Subject and Message body for the initial signature request only. Edited directly in the Docusign Template's “Message to All Recipients” settings. Impact is scoped to envelopes sent from that one Docusign Template.
• Account-Wide Resource Files - Controls the boilerplate wording for every system email (reminders, voided, declined, completed, delivery failure) across every envelope on the account. Edited via the process in Section 8.3. Impact reaches every envelope sent by this Docusign account, from every template, for every feature using this account, not just this integration.
• Header and Footer Links - Controls only the Contact Us / Terms of Use / Privacy / Support link URLs, not any other wording. Edited through the simple link screen in Section 8.2, not XML. Impact reaches every email sent by this account.

The request for signature email can come from the integration user or from the Vault CRM EM User that selected the Send for Signature button. When using the option where each email comes from the CRM user, each Vault CRM user who will send contracts for signature needs a corresponding Docusign User ID.

• Every sending user needs only a Docusign User ID, a full paid Docusign seat is not required
• The User ID is entered on the corresponding Vault CRM User record, field docusign_user_id__v. This can be entered manually by an administrator, or loaded in bulk using your organization's standard data-load process.
• The user must have consent granted for this integration before sending on their behalf will work. See Section 3.

Final Notes

Once your connection is configured and tested, avoid changing the following in Docusign, doing so can silently break the integration without any obvious error message:

• Do not revoke or re-scope Admin consent for this integration. This is the direct cause of authentication failures reported in the Integration History table.
• Do not regenerate the Integration Key's secret key or RSA key pair without immediately updating the matching values in Vault CRM, the two must always match
• Do not change the Redirect URI on the Integration Key after consent has been granted
• Do not rename Signer Role values in Vault CRM without confirming they still match the corresponding Recipient Role values configured in your Docusign Templates
• Do not edit the visible formatting of tokens in EM Contract Templates (font size or color); these must remain invisible to signers for the integration to place fields correctly
• Do not remove users or groups from a Docusign Template’s Share with Users list without first confirming the users no longer send contracts from Vault CRM. Loss of template access surfaces as a failed send, not as a permissions message.
• Do not remove a key from the Docusign Connect Keys list while that value is still saved in Vault CRM. Docusign keeps sending notifications but they fail verification; the failure displays as status updates silently not arriving rather than as an error