fmESignature Link and Composite Templates

When we released v1.0 of fmESignature Link (DocuSign Edition), our Claris FileMaker solution for integrating with the DocuSign eSignature platform, we decided on using a ‘Template’ model that supported directly uploading PDF files or using DocuSign hosted Templates. This allowed you to generate a PDF (either a static PDF or one generated from a FileMaker layout) and upload that along with a list of recipients and where they needed to sign etc, or simply specify a DocuSign Template ID and upload the list of recipients and their roles.

These supported methods for creating the DocuSign envelope from FileMaker have been easy for our customers to understand and implement in their existing FileMaker solutions. There are times though when these simple envelope creation models won’t support your requirements that might involve multiple documents/templates and authentication requirements.

For more complex envelopes DocuSign also support the composite templates model, which is the most flexible envelope creation model. With the composite templates model you can create complex envelopes which cannot be handled by the direct document or DocuSign Template models, such as when you need to send both a PDF document and include a DocuSign Template.

Some examples of composite templates that we’ve helped customers integrate over the past few years include:

  • a payment processing company needed to send a DocuSign Template that included multiple documents, in person signers and SMS verification
  • a talent agency needed to send an envelope that included both a FileMaker generated PDF as well as a standard DocuSign Template and dynamically assign recipients and roles to both documents

None of the above use cases were possible with the standard direct document/DocuSign Template models. We were able to work with these customers to create some custom FileMaker scripts and Templates in their fmESignature Link file to meet their requirements. If you would like to discuss implementing a composite template for your fmESignature Link (DocuSign Edition) integration please get in touch.

You can get more information about DocuSign Composite Templates at the following articles:

Claris Beyond FileMaker DocuSign Presentation

Last month I presented at the Claris Beyond Meetup group on integrating FileMaker with the DocuSign eSignature platform using our fmESignature Link (DocuSign Edition) solution. We had some great discussion with some excellent questions and I was able to demonstrate sending agreements from the Claris FileMaker Platform to be signed, downloading completed agreements automatically using webhooks, and accepting payments with eSignature requests.

The recording is now available and you can watch it below or directly on YouTube:

You can get more information about fmESignature Link (DocuSign Edition) on our website here. You can also request a free 14 day trial to use with a free DocuSign Developer Sandbox account by contacting us here.

fmESignature Link (DocuSign Edition) v1.5 Update

It’s been a while since we last released an update to fmESignature Link (DocuSign Edition), our FileMaker solution for integrating with the DocuSign eSignature platform. 2021 was a busy year for fmESignature Link releases – we released six updates last year with lots of new features so it’s not too surprising that the release pace was a bit slower this year.

We’ve spent lots of time in 2022 working on custom integrations for clients in Australia, New Zealand, USA/Canada and Europe. This has kept us busy but has also led to lots of new ideas for features. We’ve worked on a few composite template integrations as well which we hope to include in a future update.

We’ve just released another free update – v1.5 – which includes a number of new features, including:

  • we’ve added support for using Phone Authentication when sending Requests
  • when sending a Request for a DocuSign Template you can now pre-populate data for the DocuSign tabs such as Text tabs, which can also include a value from a FileMaker field as well as a static value. We’ve separated out the sending of DocuSign Template requests from the other Template types to simplify things and allow for more flexibility in future updates
  • downloading DocuSign Templates now includes the roles which allows us to support pre-populating the Template Tabs
  • we’ve added support for recipient access codes when sending a request to add another layer of security to ensure only the intended recipient can access the document
  • you can now download and print DocuSign Audit Events for a Request

You can find the full list of changes in the version history notes here. Existing customers can download this version from the link on your original order email (contact us if you need the link to be reset etc).

fmESignature Link (DocuSign Edition) and FileMaker WebDirect

Since first releasing fmESignature Link (DocuSign Edition) back in 2019 we’ve been asked regularly about support for FileMaker WebDirect. fmESignature Link (DocuSign Edition) was originally built for FileMaker Pro users and we didn’t do any testing or optimising for using it with FileMaker WebDirect. Over the years we’ve added support for performing scripts on FileMaker Server as well as for webhooks for receiving completed PDFs, and recently we decided to explore some options for using it with FileMaker WebDirect.

After publishing our updated guides for linking an existing FileMaker solution to the fmESignature Link file earlier this year we’ve had a number of enquiries about linking to a FileMaker solution that is accessed using FileMaker WebDirect and whether eSignature requests could be generated from a WebDirect solution. FileMaker Server has had the ability to create PDF files since v16, which is also the minimum version required for using fmESignature Link, so we couldn’t see any issues with generating a PDF from your FileMaker solution using FileMaker Server and then sending that across to the fmESignature Link file and creating a request and sending this all from a WebDirect session.

We’ve put together a new guide and a companion video that demonstrates how you can link your solution to the fmESignature Link file and create a custom PDF file and send a DocuSign request all from a WebDirect session:

fmESignature Link (DocuSign Edition) – WebDirect Linking

You will need to create a couple of new scripts to manage the process (we include some examples of these in our guide). Users of your existing FileMaker solution never see or access the fmESignature Link file directly. If you’re using FileMaker WebDirect as your primary interface and would like to incorporate sending agreements via DocuSign we think this is a great solution that you can implement relatively quickly. Please get in touch if you have any further questions or would like to schedule a live demonstration of this.

Slack Notifications for Completed DocuSign Agreements

Last this week I attended the Slack Frontiers Asia Pacific event in Sydney where the focus was on the digital HQ and how Slack can integrate with thousands of Apps. Integrating with DocuSign was a common topic in many of the sessions – Slack has a DocuSign App in their App Directory which makes connecting DocuSign to Slack very simple.

I’ve written previously about connecting FileMaker and Slack for receiving notifications for incoming SMS messages with our fmSMS solution and as I saw several demonstrations of receiving a notification in Slack that a DocuSign agreement had been signed I wondered whether I could use the same approach for our fmESignature Link (DocuSign Edition) solution. I wanted a more customised notification that included a link to the Requests record in the fmESignature Link file.

I took a copy of the FileMaker script that generates and sends the notification to a Slack channel and was able to modify this and have it up and running in under 5 minutes. I simply added the Slack Notification to the existing FileMaker script that is performed when the notification is received and processed via a webhook from DocuSign.

If you’re using Slack in your organisation we think this is a great solution to generate notifications to users when incoming messages are received. As well as the Slack channel notification you can also get a notification from your operating system (e.g. macOS or iOS) when the message is posted to the Slack channel:

Here’s a screenshot showing an example of a Slack notification generated by FileMaker Server and pushed via a Slack App/bot to a Slack channel:

Here’s a short video we recorded showing this in action as a new DocuSign agreement is completed (you can also watch this on YouTube here):

If you would like to discuss adding Slack notifications for your completed DocuSign webhook notifications please get in touch for a free initial consultation to discuss your requirements.

fmESignature Link (DocuSign Edition) Linking Guides

When it comes to integrating any of our FileMaker integration solutions there are generally two main approaches a FileMaker developer can take:

  1. Linking – this involves using our solution’s file as a ‘interface’ or front-end file to your existing FileMaker file. This is a relatively quick way to get up and running – you relink the table occurrences to reference the matching tables in your existing FileMaker file (e.g. Contacts) and then update the layouts and add any new fields. You also need to update any field references in scripts and create any new value lists. Using this method you can be up and running in around 30 minutes.
  2. Embedding – this is the most complex and time consuming type of integration as it involves recreating the required functionality our solution’s file in your existing FileMaker solution. You need to complete the required tasks in a certain order – whilst most of the code can be copied across you will need to manually recreate table occurrences and relationships. This method can take many hours to complete depending on how much functionality from our solution you wish to move across to your FileMaker file.

We’ve always published Integration Guides that cover the embedding process and detail the steps that you should follow to incorporate functionality from one of our solution files in your existing FileMaker solution. Linking has always been more difficult to document as each of our customer’s solutions are different and the process will never be the same from one customer solution to another. To help get you started with linking and demonstrate the process we’ve put together a two part series that covers linking the FileMaker Contacts starter solution with our fmESignature Link (DocuSign Edition) solution.

In Part 1 of the Linking Guide we cover how you can link the fmESignature Link file to your existing FileMaker solution and use the fmESignature Link file to send eSignature Requests to your Contacts. We’ve included step-by-step instructions as well as a companion video that demonstrates the process which should take around 20-30 minutes to complete. We’re simply replacing any references to the Contacts table in the fmESignature Link file with references to your Contacts table. The Contacts starter solution has separate tables for Contact details such as name and company name and separate tables for storing email addresses, phone numbers and mailing addresses so it’s a good example for demonstrating how to incorporate data from multiple tables.

By the end of the process you will be able to use the fmESignature Link file to view your Contacts from within the fmESignature Link file and send an agreement to one or more of your Contacts.

In Part 2 of the Linking Guide we take this a step further and demonstrate how you can generate eSignature Requests from your FileMaker solution using PDFs created from layouts in your existing FileMaker file. We’ve added a new layout to the Contacts starter solution that contains the agreement we wish to send to and we’ve added some anchor tags to the layout to specify where we can our DocuSign tabs to appear. Once we’ve created a new Template in the fmESignature Link file for this new agreement we can then create a script in the Contacts starter solution that performs a number of tasks, including:

  • captures the Contact/Recipient details such as their FileMaker Primary Key/ID and email address
  • creates a PDF using the contract layout
  • creates a new record in the Requests table in the fmESignature Link file and sets the Template ID to use and the PDF to send that you’ve previously created
  • adds the Contacts as a recipient to this new Request
  • takes the user to the newly created Request record so they can review this before sending out the agreement

The guide includes an example script that you can reference when implementing something similar in your FileMaker solution. Once again we’ve included a companion video that demonstrates the steps involved which should take around 30 minutes to complete.

Presentation to Atlanta FileMaker FileMaker Developers Group Recording Now Available

I recently did a presentation to the Atlanta FileMaker FileMaker Developers Group for their October 2021 meeting. The topic of my presentation was integrating the FileMaker Platform with the DocuSign eSignature platform using our fmESignature Link (DocuSign Edition) solution.

The recording is now available and you can watch it below or directly on YouTube.

fmESignature Link allows you to automate the management of electronic document signing: you can generate and send agreements to be signed electronically using your familiar FileMaker interface and download the completed agreements back into FileMaker.

I also did a brief demonstration of how you can send and receive MMS messages using the FileMaker Platform and our fmMMS solution.

fmESignature Link (DocuSign Edition) Now Supports SMS Delivery

When DocuSign recently announced the availability of SMS Delivery we knew this would definitely be a feature we would be supporting in fmESignature Link (DocuSign Edition), our Claris FileMaker Solution for integrating with the DocuSign eSignature Platform. Databuzz pioneered the sending of SMS messages directly from the FileMaker Platform 20 years ago and fmSMS, our FileMaker solution for sending/receiving SMS messages, has been used since then to send millions of SMS messages by organisations all around the world.

SMS is perfect for personalised notifications that you need the recipient to read and respond to quickly. Research shows that SMS open rates are as high as 98%, compared to just 20% of all emails. And, on average, it takes 90 seconds for someone to respond to a text and 90 minutes to respond to an email.

With DocuSign’s SMS delivery you can reach signers wherever they are, in the way they prefer, through real-time notifications sent directly to their mobile device – enabling them to quickly open and electronically sign documents. Some key benefits of SMS delivery:

  • Reduce completion time for agreements
  • Reach signers who don’t have or don’t want to use email
  • Increase successful transaction rates

fmESignature Link 1.41 includes support for sending requests with SMS Delivery. SMS Delivery allows you to notify signers via SMS in addition to the standard email notifications. Recipients will receive an SMS notification on their mobile phone like the following:


and can click the link and sign the document directly on their mobile device. Combined with DocuSign’s Responsive Signing functionality you can present documents for review and signing that are mobile friendly based on the signer’s device:

We have a new article on our support site that covers all the details for sending requests with SMS Delivery from fmESignature Link.

The full list of changes are listed in the version history notes here. Existing customers can download this version from the link on your original order email (contact us if you need the link to be reset etc).

fmESignature Link (DocuSign Edition) Updated to Use Authorization Code Grant OAuth Flow

When we were originally developing v1.0 of fmESignature Link back in 2018/2019 one of the first decisions we had to make was which of the three OAuth Types we should choose for handling the authentication with the DocuSign API: JWT Grant, Authorization Code Grant or Implicit Grant. Each flow has its pros and cons and we eventually settled on using the JWT Grant OAuth Flow. The main advantage of using the JWT Grant is that it doesn’t require a user to be present after initially gaining consent. The downside to using the JWT Grant is that FileMaker Pro cannot natively generate the JWT (JSON Web Token) required as part of the flow in requesting the access token that you ultimately need.

We found a workaround using a FileMaker Web Viewer and a JavaScript function that we could pass parameters to which would generate the JWT and return that as a parameter to a FileMaker script called via the FMP URL protocol. The downside to using a FileMaker Web Viewer is that this cannot be performed as a FileMaker Server script (either via Perform Script on Server or as part of a script scheduled using the Admin Console). We created some PHP files that used either the Data API or the older PHP API to handle scripts that needed to run under FileMaker Server.

We were never 100% comfortable with using the Web Viewer and as more customers have deployed and integrated fmESignature Link over the past few years we have become aware of some further limitations with using this approach. We’ve had reports that the FMP URL script wasn’t firing all the time, particularly on Windows and iOS. Troubleshooting these is particularly challenging and we often struggled to reproduce them in our own testing. Another downside to the Web Viewer approach concerned when the FMP URL script would run if you had a long running FileMaker script that you wished to incorporate the sending of a request to DocuSign. You couldn’t always control when the FMP URL script would run – at least until FileMaker Pro 19.1.3 was released. As we support all versions of FileMaker Pro from v16 onwards we couldn’t rely on this either. On Windows the script we wanted to run immediately after the Web Viewer loaded was added to the end of the FileMaker script stack and would run when the currently running FileMaker script finished, by which time the context had changed and it was too late for our script!

After implementing a similar version of the Authorization Code Grant OAuth Flow for our fmAccounting Link (Xero Edition) solution in 2019 we became convinced that this would ultimately be a much better experience for our fmESignature Link (DocuSign Edition) solution as well. It would require the user to perform an initial approval inside of the fmESignature Link file but after that we can programatically refresh the tokens without user intervention. This can also be setup a server schedule so that the token is refresh daily/weekly etc so that it will never expire.

We’ve just released v1.4 of fmESignature Link which now uses the Authorization Code Grant OAuth Flow instead of the JWT Grant OAuth Flow. If you’re currently using fmESignature Link v1.36 or earlier and everything is working well for you there’s no need to rush out and change anything here. You can continue to use the JWT Grant OAuth Flow if it’s working well for you.

If you have encountered some of the issues described above and would like to simplify the authentication and remove the dependency on the Web Viewer then you can update your existing integration using the latest version of the fmESignature Link file. We’ve put together a number of new and updated support articles to assist you with this process:

fmESignature Link (DocuSign Edition) Getting Started Guide

Authorization Code Grant OAuth Flow Setup Video

Authorization Code Grant OAuth Flow Details

Converting from the JWT Grant to the Authorization Code Grant OAuth Flow

All of the changes can be copied across from the v1.4 file into integrations using earlier versions of fmESignature Link and the process should generally take around 30 minutes to complete. In addition to the new fields, scripts and layout that you can copy across you only need to update two existing FileMaker scripts and one existing FileMaker layout. We’ve tried to keep these changes to a minimum and none of the scripts that send requests to the DocuSign API will need to be updated.

Other Changes in v1.4

In addition to the Authorization Code Grant OAuth Flow changes outlined above we’ve also include some new features in this release, including:

  • added support for PDF Form Fields transformation and a new Template Example for this
  • added support for Radio Group Tabs
  • updated Webhooks to use JSON notifications for the the eventNotification webhook (change from XML)

The full list of changes are listed in the version history notes here. Existing customers can download this version from the link on your original order email (contact us if you need the link to be reset etc).

Now that we have the Authorization Code Grant OAuth Flow changes out of the way we are working on adding support for SMS Notifications to fmESignature Link and hope to have this released shortly.

fmESignature Link (DocuSign Edition) Now Supports DocuSign Payments

Version 1.35 of fmESignature Link (DocuSign Edition) has just been released and it includes a number of exciting new features that we’ve been working on over the past few months. Here is a brief summary of the main new features in this release.

DocuSign Payments Support

With fmESignature Link you can now send an agreement to be signed which also includes a request for payment using DocuSign Payments. Customers can pay with a credit card, debit card, Apple Pay, and Google Pay using one of the supported Payment Gateways. Connecting payments and agreements into a single workflow reduces payment delays and provides a superior customer experience by allowing customers to sign and pay from almost anywhere in the world on most devices in one transaction.

DocuSign Payments are great for agreements that have and associated payment such as membership renewals, deposits, event registrations, rentals and payment authorisations.

When you send an agreement with an associated payment request the recipient is prompted to make the payment after signing the agreement:

Here’s a short video demonstrating DocuSign Payments with fmESignature Link (you can also watch this on YouTube here):

We have a new article on our support site that covers all the details for setting up DocuSign Payments and creating a template in fmESignature Link which includes a payment request.

Carbon Copy Recipients

You can now include recipients who don’t need to sign but do need to receive a copy of the completed agreement:

Check out our new support article for all the details on including carbon copy recipients.

Recipient Language Settings

You can now specify the language for signers that will be used in the DocuSign email notifications and the online signing ceremony. For example you could specify French for one signer and German for another if that is their preferred language:

This article in our support site has all the details for specifying the recipient language.

The full list of changes are listed in the version history notes here. Once again this is a free update and existing customers can download this version from the link on your original order email (contact us if you need the link to be reset etc).