A contract generated from a Dataverse record eventually needs a signature, and that's the point where a process that stayed inside the tenant right up until the document itself gets generated starts touching infrastructure Microsoft doesn't run end to end. The signing service has to receive the file and has to be trusted to produce something that holds up if a court ever looks at it. Then it has to hand a result back that lands cleanly on the original Dataverse record. Dynamics 365 itself does none of that natively.
None of Dynamics 365's other signature-adjacent features close that gap either. Finance & Operations has a signing capability, but it's built for internal approvals on critical business processes, tied to a certificate each user requests through their own Options page. Getting a customer to execute a contract is a different job entirely. Field Service has a signature control that captures a customer's mark on a mobile screen during a service visit. That's a capture mechanism, useful for confirming a visit happened, and it doesn't carry the cryptographic verification a signing service provides. Customer Service's email signature feature is just an agent's signature block on outgoing mail. Dynamics 365 Sales has nothing documented in this area at all.
What Microsoft ships first party for signing
The product built for this job is Microsoft Syntex eSignature, and it lives inside Microsoft 365. Dynamics 365 and Dataverse sit outside that product entirely. Microsoft's own documentation lists it as generally available worldwide, with the single exclusion of Indonesia. PDF signing works everywhere it's available. Word document signing works worldwide too, for users on the Beta, Current, and Monthly Enterprise Channels.
The catch that matters for a Dynamics 365 architect is where the file has to sit. Native eSignature requests are created from PDFs stored in SharePoint, and external recipients get in through Microsoft Entra ID B2B guest access. The service only works at the SharePoint site level. Subsites aren't supported. Only unencrypted PDFs work with the native service, according to Microsoft's send-requests documentation.
Licensing runs per transaction. There's no seat count involved, no per-user licence tied to the sender, and recipients don't need a SharePoint licence or even a Microsoft account to open and sign a request. What the tenant does need is an Azure subscription linked for pay-as-you-go billing, and each signature request costs $2.00, covering up to ten recipients on that one request, per Microsoft's Syntex pricing page. Through June 2026, tenants with pay-as-you-go billing configured get five free requests a month before the meter starts running. That billing sits outside standard Azure consumption, so it doesn't draw down against a Microsoft Azure Consumption Commitment.
OCR-scanned files, whether PDF, image, or TIFF, cap out at 500 pages. A single request can carry up to 50 signature fields across the document. The underlying file size ceiling is SharePoint's own 250 GB per-file limit, generous enough that it will never be the constraint on a contract.
The connector route through Power Automate
Outside Syntex, Microsoft's connector catalogue lists seven dedicated electronic signature connectors for Power Automate and Power Apps, each sitting at a specific licensing tier. DocuSign and Adobe Acrobat Sign are both Standard tier, as is a third from a document automation vendor. SignatureAPI, E-Sign, and Connective eSignatures all sit at Premium. Autenti E-Signature Workflow is Premium as well, and it's currently in preview.
That's the route for a team that wants to sign a document from Dynamics 365 without ever routing through SharePoint's Syntex layer. Call the connector directly from a Power Automate flow triggered off the Dataverse record, hand it the file, and process whatever comes back inside that same flow.
Adobe Acrobat Sign and DocuSign show up twice in this picture, and the two integrations work differently. Inside Syntex, they're built in as external signature providers, so Microsoft doesn't charge anything extra for routing a request through them there. The provider's own licensing terms apply, and the provider handles the signing process and every notification along the way. Called directly as their own Power Automate connectors, they behave as a separate integration with their own connector-level rules.
Where the document actually goes to get signed
Storage location changes depending on which path sent the request. For the native eSignature flow, a working copy sits in a hidden document library in SharePoint for the duration of signing, retained for five years or according to whatever retention policy the SharePoint or tenant admin has set. Once a request reaches a terminal state, whether that's completed, cancelled by the sender, or declined by a recipient, no further action is possible on it, and recipients get 30 days to view, download, and keep the document before that access closes. Cancel a request early and access disappears immediately for anyone who hadn't finished signing.
When Adobe Acrobat Sign or DocuSign handles the signing as an integrated provider, the completed copy saves back to SharePoint automatically once every party has signed. Since September 2025, rolling out through November that year, it saves into the original folder the source document came from. Before that change, signed copies from third-party providers landed in a provider-specific folder, and that fallback still applies today if saving to the original folder isn't possible. The filename gets the provider name, the word signed, and a timestamp appended to the original name. A declined or cancelled request never produces a saved copy.
None of this touches Dataverse. The document sits in SharePoint through the entire signing process regardless of which provider handled it, which raises the same question covered in what leaves your tenant during document processing. Once a connector hands the file to DocuSign, Adobe, or any of the other five signature connectors in the catalogue, that file sits on the vendor's own infrastructure for as long as signing takes. A tenant with residency requirements needs to know that before picking a connector. Finding out after the first contract has already gone out is too late. External access adds its own friction. Conditional access policies can block an external recipient from signing at all, a sensitivity label on the source site can stop a request going to an external party in the first place, and deleting a guest account mid-signature cuts that recipient off from both the request and the eventual signed document.
What the eIDAS and ESIGN tiers actually mean
Europe's eIDAS Regulation recognises three tiers of electronic signature, and they aren't interchangeable. A simple electronic signature has almost no formal requirements. Typing your name under an email can count. An advanced electronic signature has to be uniquely linked to the person signing, created using data only that person controls, and built so that any later change to the signed data is detectable. A qualified electronic signature is an advanced signature that also uses a qualified certificate with the private key stored on a certified device, and it's the only tier that carries the same legal weight as a handwritten signature across every EU member state.
Microsoft's own documentation says Syntex eSignature uses simple electronic signatures under eIDAS and other applicable laws. That's the tier every contract gets by default through the first-party flow, regardless of the value written into it.
In the US, the ESIGN Act defines an electronic signature broadly, as a sound, symbol, or process a person adopts with the intent to sign, and it says a signature or record can't be denied legal effect just because it's electronic. For consumer transactions specifically, ESIGN also requires the consumer to give consent and receive clear disclosure before electronic signatures replace paper ones.
Which tier a given agreement actually needs, and whether ESIGN's consumer disclosure rules apply to a particular contract, is a question for a lawyer rather than an architect.
Getting the signed file back into Dataverse
Dataverse document signing doesn't end when the signature lands. The file still has to get back onto the record it came from, and Microsoft's platform gives two standard mechanisms for that, attachments and file columns. Attachments store as Base64-encoded strings, either in the ActivityMimeAttachment.Body column or the Annotation.DocumentBody column, depending on which entity holds them. File columns work differently and can't just be set on a normal create or update operation. Creating, retrieving, updating, or deleting the binary data behind a file column requires its own specific methods, per Microsoft's developer documentation.
For anything signed through Adobe Acrobat Sign or DocuSign inside the Syntex flow, there's an extra step because of how the process is built. The signed document saves to SharePoint first, since that's where the eSignature service places it, before it can go anywhere else. Getting it into Dataverse means downloading it from SharePoint and attaching it to the record, which usually means building a Power Automate step specifically for that handoff.
Tamper evidence rides along with the file. Once every recipient signs, the native service digitally signs the completed document with a Microsoft certificate so it can't be altered afterward, and appends an audit trail to the PDF itself covering the request's creation date, when each recipient signed, and the other activities that happened along the way. Microsoft Purview's audit log captures the same events separately, covering request created, sent, cancelled, declined, completed, link expiration, document viewed, signed, and downloaded. Retention on that log defaults to 180 days for non-E5 and guest users, and stretches to ten years with the add-on licence Microsoft sells for exactly that purpose. Finance & Operations handles evidence differently again, tying every signature to a certificate issued per user, with a private key validated at signing time and a signature log that can show whether data was altered after the fact.
None of that evidentiary chain is something an architect gets to design. Which eIDAS tier a signature counts as and how long Purview holds onto its logs are both fixed by whichever provider and licence tier the business already picked. What actually sits within an architect's control is the seam on either side of that gap, the document that goes out, generated in a known state from the Dataverse record it belongs to, and the flow built to pull the signed result back before anyone downstream comes looking for it.