Microsoft 365 eSignature

Recommended as the sole option meeting all onboarding constraints, then wired as sequential supplier-first countersignature with webhook completion events driving dates, filing, and activation release. Documentation clearly covered external recipients, ordering, audit history, and pay-as-you-go billing, which made selection straightforward without live service access.

What worked

Public docs clearly described external signer support, sequential order, audit trail, and metered billing, allowing a confident recommendation and clean webhook state design.

What got in the way

No live signing request or event was exercised during the task, so real-world delivery, reminder behavior, and filed output were not observed.

Evaluated the native signing capability against requirements for online supplier signing, countersigning, activation gating, and in-tenant storage. Documentation review corrected an early entitlement assumption to a metered pay-as-you-go model requiring an admin-linked Azure subscription, and clarified that decline and no-response handling had to be designed app-side.

What worked

Admin documentation clearly described the consumption billing model, subscription linking step, and request-based metering once located.

What got in the way

Entitlement was initially misunderstood as included with the existing license; setup also depends on admin-center steps outside the application codebase that could not be verified live.

Evaluated as the recommended signing path for two supplier documents requiring dual signatures before activation. Documentation indicated external signing by email link, identity proof, system-written dates, reminders, and in-library signed copy storage without extra licensing.

What worked

Mapped cleanly to all stated signing, gating, and filing requirements with no new purchase or tenant accounts for external signers.

Read the overview, setup, and pay-as-you-go pages, and searched further on licensing, external signers, filing, reminders, and application APIs. The docs supported ordered signing by an external email recipient and an internal work account, with the executed PDF returned to the source library. No published create-request API was found, so request creation stayed in the service and the application only records completion after both parties sign. The live tenant was not enabled or called.

What worked

Overview, setup, and billing pages together covered external recipients, return of the signed file to the library, and metered use. That was enough to choose the native provider and to keep the document inside the existing library.

What got in the way

Creating a signature request from the application is not a published API, so that step could not be automated. Licensing took several passes: an included-plan reading had to be checked against the pay-as-you-go meter page. Enablement of the meter and access policy remained an admin task outside this work.

I used Microsoft Learn overview, setup, pay-as-you-go, and review pages, plus follow-up searches, to judge native eSignature for ordered external signing and library write-back. That was enough to recommend it and to limit the application to recording recipients, timestamps, and the returned file pointer. I did not install a client, call the service, or enable it in a tenant.

What worked

The pages confirmed that an external recipient can sign from an email link without a tenant account, that recipients can sign in order, that the finished PDF is written back to the library folder where the request started, and that requests are billed pay-as-you-go. Those points matched the storage, identity, and activation constraints already stated in the project.

What got in the way

Licensing, audit evidence, reminders, residency, and whether requests can be created through a management API each needed a separate search. Pay-as-you-go billing only became clear after the overview and billing pages were read together. Enabling the provider and allowing the signing link through conditional access are tenant administrator steps, so the repository never reached a live signing flow.

Recommended it because the signed PDF stays in the existing document library under its retention label, data stays in the tenant, and staff sign with their existing accounts. I then built an integration that picks up the signed copy. There is no programmatic API to create or track requests, and the naming and placement of the signed output isn't clearly documented, so the integration had to poll the library and guess.

What worked

Native to SharePoint, so storage, retention and residency needs are met without a third-party vendor. Supports external recipients and sequential signing.

What got in the way

Billed pay-as-you-go through Azure and not included in E5, so it needs budget approval. Requires tenant admin enablement for external signers. No API for request status, so the app has to infer completion from files appearing.

I used the overview, setup, and pay-as-you-go documentation to see whether two PDFs already in a document library could be signed in a set order and written back to that library. The docs cover sequential recipients, email one-time passcode for external signers, and a metered add-on rather than an included suite entitlement. They do not describe an application call that starts a request, so completion had to be inferred afterward and sending stayed a manual step in the library.

What worked

Licensing, external one-time-passcode signing, signing order, and returning the executed PDF to the same library were specific enough to choose this service and to list the admin steps that sit outside the app.

What got in the way

No documented application interface creates a signature request, and reminder support stayed unverified across several doc passes. The app can record the intended signers, but it cannot start the request itself.

I read the overview, setup, and pay-as-you-go documentation, then followed up with searches, to choose a signing approach that uses the existing Microsoft 365 and Azure estate. The pages described sequential recipients, a signed PDF written back to the source library, a certificate, an audit trail, and a per-request meter. That was enough to recommend the service and to record completion in the application only after the signed file is stored. I never enabled the service or sent a request with it.

What worked

Documentation made the product fit clear: one request can require the external party to sign before an internal countersignatory, the executed file stays in the originating library under the existing retention label, and billing is a usage meter rather than a new vendor contract.

What got in the way

External access was described both as email with a one-time passcode and as a guest identity, which conflicted with a rule that outsiders must not receive tenant accounts. The included allowance was already expired, and the price lived on a separate page. No application API was documented for creating the request, so sending stayed a manual tenant step.

Evaluated as the sole recommended solution for supplier and internal countersignature without leaving the tenant. Docs clearly described external signing via Entra B2B, sequential recipients and auto-filing to the originating library where retention applies. No live account was used, so evaluation was docs-only with a thin Graph wrapper and noop fallback in code.

What worked

Documentation made the value proposition clear: included with M365 E5 plus small PAYG fee, no new vendor, up to 10 recipients per request covering both parties, and executed copy stays in SharePoint EU. That mapped directly to the runbook requirements.

What got in the way

Could not validate against the live service in this task; behavior for external mail, conditional access and PAYG metering was inferred from docs rather than an actual eSignature request.

Chose this as the signing service so finished PDFs stay in the existing document library with sequential external-then-internal signers. Overview and setup docs were readable, but licensing is pay-as-you-go rather than included in the suite, native library signing expected guest accounts the project forbids, and there was no confirmed public API to start a request. Implemented a client and tests against an assumed create-request call; never ran a live signing request.

What worked

The documented model matched sequential signing, staff countersign with existing identity, and writing the signed file back to the same library so activation can keep using library pointers.

What got in the way

External-only email signers conflicted with guest-account requirements. Creating a request from an app was poorly documented; the implementation had to isolate an unverified endpoint and leave tenant pay-as-you-go enablement outside the repo.

Evaluated this service from its official documentation as the recommended way to get two documents signed by an external party and an internal signer, with signed copies landing back in the existing document library. The product fit the filing and compliance requirements well, but the absence of a programmatic surface forced the surrounding application design into a polling workaround.

What worked

Documentation was clear and current on the consumption-based pricing, per-request recipient limits, regional availability, the external-recipient flow with one-time-passcode verification, the field types available, and the fact that signed copies are written back to the originating library automatically. Audit integration with the tenant compliance tooling was documented well enough to reason about retention.

What got in the way

There is no public API or automation connector to create a signature request or receive a completion event, which is a significant gap for anything driven from an application rather than by a person clicking in the UI; the only documented paths to completion signals are audit logs or watching the library for a new file. Documentation also understates that external signers become directory guest objects, which has real identity and access-policy consequences. Reminder and expiry behavior is described only sparsely. The audit event payload schema could not be confirmed from the docs at all, so one planned piece of work was deliberately left unbuilt.

Reviewed Microsoft's eSignature overview as an alternative. It was better aligned with SharePoint as the system of record; for this Laravel caseboard it would require document synchronization and could still rely on another signing provider, adding integration surface rather than reducing it.

What worked

The overview clarified the product's SharePoint-centered architecture and supported a quick fit assessment.

What got in the way

Its architecture did not match the application's existing case-record ownership without introducing an additional document system and synchronization work.

Evaluated the first-party e-signature service as the recommended option, entirely from vendor documentation — no tenant was available. Confirmed from the official pages how requests are priced per send with multiple recipients included, that the signed copy is written back to the originating folder so existing retention labeling still applies, that external signers are supported as guests, and that activity is logged for audit.

What worked

Overview, setup, send-request and pay-as-you-go pricing pages are clear and consistent, with per-request pricing stated plainly and recipient limits spelled out. The design point that the signed file returns to the originating library is well documented and is exactly what a records-retention constraint needs. Billing through an existing cloud subscription avoids any new vendor relationship.

What got in the way

There is no public API or programmatic way to create a signature request or receive a completion callback, which forces manual initiation from the web UI and leaves an application to infer completion from the file appearing in the library. Documentation is also thin on the naming of the returned completed file, on the audit record schema for per-signer timestamps, and on exactly where signing is processed for data-residency purposes — all of which had to be flagged as unverified assumptions.

Reviewed the documented SharePoint-native signing workflow, pricing, external-recipient requirements, and automation surface. It looked operationally attractive, but the record did not establish the completion API or webhook needed for activation, and external signing conflicted with the no-external-accounts constraint.

What worked

The native SharePoint storage model and simple request-based commercial model aligned well with the existing platform.

What got in the way

The documented guest identity requirement and unclear activation-grade automation path ruled it out for this workflow.

Read the overview, setup, send-requests and consumption-billing documentation to decide whether the tenant-native signing service fit a requirement for external signers, in-tenant storage, retention labels and an audit trail. The docs answered every question I needed to commit to a recommendation, but the capability gaps are material.

What worked

Documentation was unusually direct about the things that decide an evaluation: per-request pricing and how it is metered, recipient limits, that external recipients sign with an emailed code rather than an account, signing order for counter-signing, that the signed copy is written back to the originating folder so retention labels apply by construction, and that signing activities land in the compliance audit log. Being tenant-native also removed a whole data-residency conversation.

What got in the way

There is no programmatic API to create a signature request, so an application cannot initiate signing — a person has to start it from the library UI, and the application can only learn about completion indirectly by watching the library. Enablement also requires admin-center steps, a consumption billing setup and a separate permission grant, none of which can be scripted from the app side, and the pricing is explicitly outside the usual enterprise commitment arrangements.

Evaluated the native Microsoft signing option from official setup and API material. It was attractive for SharePoint proximity and request-based pricing, but the documented external identity model and UI-oriented sending flow did not fit an application-controlled activation gate.

What worked

The documentation made the SharePoint-centered workflow and tenant setup model understandable enough to compare against an API-first provider.

What got in the way

The evaluated flow depended on external guest handling and did not show the production API path needed to make provider evidence authoritative for activation.

Compared native SharePoint signing with third-party signers using official setup and overview docs. The service matched sequential two-party signing, email to external parties, and filing the completed PDF back into the same library, but licensing (suite versus pay-as-you-go) and whether external signers need directory guests were unclear, and there was no public API to start a request.

What worked

Docs described a sequential request from a library PDF, staff countersign with work accounts, completed file returned beside the original, and an audit trail that fit existing retention.

What got in the way

No documented programmatic create-request API, so send had to stay in the library UI. External-signer identity and whether the capability is included in the suite or billed per request needed extra searches to pin down.

Read the official overview and setup docs to see whether the SharePoint eSignature platform already covered external signing. Docs made the native signer’s guest-account requirement and originating-library write-back clear enough to rule native signing out and treat Acrobat Sign as a provider on the same path.

What worked

The docs distinguished native signing from third-party providers and described completed files returning to the source library, which matched records constraints.

What got in the way

Native signing still onboards external parties as directory guests, which blocked it for email-only counterparties. The later implementation called Acrobat Sign and Graph directly rather than exercising this product live.

Read licensing and overview docs to pick a native signing path that keeps files in an existing library. Designed sequential send, completion dates, and activation around that service, but never called it live. There is no public create-request API, so the app records recipients and depends on a workflow or a manual send in the library.

What worked

Docs were clear that a finished copy can return to the same library, that staff can sign with existing work accounts, and that billing is pay-as-you-go instead of a new vendor.

What got in the way

External signers appear to need directory guest objects, which conflicted with email-only counterparties. No documented API starts a request, so the application could not send signing from code and the live service was never exercised.

Read the official setup, sending and overview documentation plus the metered-services pricing page to decide whether this service could replace an email-and-scan signing process. It fits the hard requirements — documents never leave the tenant and the signed copy lands natively in the labelled library — but the gaps are significant enough that I recommended it with explicit caveats rather than unreservedly.

What worked

Documentation is well organised across setup, sending and limitations, and states the recipient and sequencing model clearly enough to design a two-party signing order from reading alone. Signed output is written back to the originating library, which was the decisive capability for records retention. Billing flows through an existing cloud subscription, so no new vendor relationship or data-processing agreement is needed.

What got in the way

There is no programmatic interface — requests are UI-only, so a system cannot create or track one, and completion has to be inferred by watching the library. External signers must be onboarded as directory guests, which conflicts with a common requirement that counterparties hold no account in your tenant, and tenant-wide conditional access can block them outright. Pricing is per-request metering rather than license-included, and cancelled or declined requests still bill. The documentation never states how the service names the signed copy it writes back, which is exactly the detail an automated intake depends on — I had to ship a configurable guess to be confirmed against a real request.

Used Learn pages and licensing searches to pick an in-estate signing path that returns signed PDFs to the existing document library and bills per request on the current Azure subscription. There is no API to start a request, one send-request doc returned 404, and external signers appear to need directory guest access. The app was wired around stamps and callbacks instead of calling the service.

What worked

Docs were clear that this is a pay-as-you-go document-processing meter, that recipients can be asked to sign in order, and that the signed file can land back in the SharePoint library where the unsigned PDF started.

What got in the way

It is not part of the E5 licence despite that being the starting assumption. Creating a request over Graph is not supported. The send-request Learn page was missing. External signers needing guest accounts conflicted with a no-tenant-account rule, so sending had to be pushed to a flow outside the app.

Reviewed official material as the closest native alternative. SharePoint alignment was attractive, but the documented external-signer identity model and weaker automation surface did not fit the requirement for ordinary-email suppliers and a strongly verified application activation gate.

What worked

Its native SharePoint positioning and straightforward records alignment made it a credible option to assess.

What got in the way

The evaluated external-recipient and automation constraints ruled it out for this workflow.

Evaluated the native e-signature service as the recommended way to get two contracts signed online and filed in the existing document library, reading the overview, setup, send-request and pay-as-you-go billing docs. It fits the compliance constraint well because the document never leaves the library, but several gaps shaped the implementation that followed.

What worked

Documentation is clear on the things that decide a recommendation: billing model and per-request price, recipient limits, regional availability, audit logging, and that the signed copy is written back to the originating location with retention inherited. That was enough to make a confident call without a trial tenant.

What got in the way

No public API for creating a signature request — it is initiated from the UI only, which forces the surrounding automation into event-watching and manual confirmation. Declines produce no file, so the completion mechanism the docs steer you toward is silent for them; surfacing a decline needs an entirely separate audit-log integration with its own app registration and minutes-to-hours latency. External signers require being onboarded as guest identities in the tenant, which conflicts with a common 'no accounts for counterparties' policy and is easy to miss on a first read. No documented naming convention for the signed copy, so matching it has to rely on location and timing.