Automating Document and e-Signature Processes in Adobe Workfront with Fusion | by Wes Hopkins | Aug, 2022

Adobe Workfront is a powerful system for managing the planning and execution of work. The promise of a paperless process is one of the many reasons why customers choose to adopt project management systems like Workfront.

However, even after ‘going paperless’, many organizations still have processes that require the creation of documentation and the gathering of signatures. Consider the management of a client project and the creation and management of a Statement of Work document: new projects or changes to existing scope require documentation and acceptance via signature.

Even with digital tools, the steps to make the documentation are still manual — you need to fill out a template with project information, send the document to the recipient, sign it, receive and store the signed copy, and finally — update the project and tasks accordingly.

Of course — this being a Tech Blog article — we’re going to show you how this and other manual document processes can be completely automated using Adobe Workfront, Adobe Workfront Fusion, Adobe PDF Services, and Adobe Acrobat Sign.

Before you dive into the how-to, if you’d like to see some context, check out our session at Adobe Summit where Ben Vanderberg and myself highlight this exact use case.

We’re going to automate the creation, transmission, reception, and management of a Statement of Work document with Adobe Workfront Fusion, Adobe Workfront, Adobe PDF Services Connector, and the Adobe Acrobat Sign Connector.

Before we start, you’re going to need a few things:

This article focuses on the steps to create the document automation process in Fusion. Accordingly, we’ll outline — but move quickly through — the supporting topics and so this article assumes that you already have a working knowledge of:

So, with that, let’s…

“I want to be able to generate a Statement of Work document for any project in Workfront, send it to a client, have them sign it, and update my project when the signature is received”.

The steps

As we think of how to automate this process, let’s break down this problem statement into the manual steps a person would perform to complete it.

• Open a Statement of Work template in a word processor
• Fill in the template with information from the project copied from Workfront
• Save the completed template as a PDF
• Send the PDF to the customer for e-signature using Adobe Acrobat Sign
• Wait for the customer to sign it
• Receive the email notification that the document has been signed
• Retrieve the signed document from Adobe Acrobat Sign
• Store the signed Statement of Work document in the project in Workfront
• Update the project information in Workfront to indicate the client has approved the work.

The components

By looking at the steps above we can enumerate the components we need to orchestrate.

• A customer project in Workfront —We will generate a Statement of Work for this project, querying the list of tasks and writing them in our template.
• A template for the Statement of Work — in Microsoft Word .docx format, the thing we’re going to fill with project information.
• Automated scenarios in Workfront Fusion — two. One scenario is to generate and send the document and a second scenario is to receive the signed documents and update our project.
• A trigger — Ordinarily a person would “know” it’s time to start the process and just do it, but for automation, to work we need some sort of measurable event — an action that a user can perform that will cause the generation process to start. There are many ways we can initiate scenarios in Fusion. In our example, we’ve opted to use the event of creating a new issue in a request queue to be our trigger. So that means we need…
• A Request Queue and project in Workfront — a place to collect requests for new Statements of Work. When issues are created in the queue, our first scenario will run.
• A Workfront Custom Form — We want to collect the customer’s name and email address for our Statement of Work in our request. We’ll use a custom form associated with the Request Queue to do this.
• Adobe PDF Services API — this will merge the information from our Workfront project into our document template and generate our Statement of Work PDF.
• Adobe Acrobat Sign API — this will take care of sending the document for e-signature and notifying us when the recipient has signed it.

After looking at the steps and our tools we now have a better idea of what our automated Statement of Work process will look like.

Project manager (Manual)

• Create a new “Statement of Work” request in Workfront. Provide the project, customer name, and email address.

Fusion Scenario 1 — Generate and Send Statement of Work Document (Automated)

• Begin processing upon ‘new issue’ event trigger
• Query the customer project referenced in the SOW issue.
• Download the SOW document template
• Merge the project details into the template with PDF Services API
• Send the document to the recipient with the Adobe Acrobat Sign API
• Update the SOW request issue to indicate it is out for e-signature
• Move the issue from the request queue into the customer project issue list

Customer/Recipient (Manual)

• Receive Adobe Acrobat Sign email requesting a signature on the Statement of Work document
• Sign the statement of work document

Fusion Scenario 2 — Receive Signed Statement of Work Document (Automated)

• Begin when the recipient (Acrobat Sign Trigger) has signed the document
• Download signed document from Adobe Acrobat Sign
• Upload signed statement of work into Workfront on the customer project
• Update the SOW request to indicate it is completed.

Now we know what we need to build; let’s get to it.

Before we build the request queue, we need to build a custom form to capture the details of our Statement of Work generation request. If you’re not yet familiar with creating custom forms in Workfront, please see this documentation.

Here’s what the completed form looks like in the form editor:

It is an issue form and has five required fields.

• Customer Project — Typeahead, referencing the Project object type
• Customer First Name — Single Line Text Field
• Customer Last name — Single Line Text Field
• Customer Email — Single Line Text Field
• Note to Customer — Paragraph Text Field

Ensure to set the form sharing to system-wide, or to the appropriate user groups you need for your purposes.

Next, we’ll create a new project to house our Statement of Work request queue.

• Go to the waffle menu (top right corner) and click Projects
• Create a new project. call it “Statement of Work”
• Set status to “Current” (otherwise queue won’t show)
• Create a task reminding users not to add tasks to it 🙂

Now set up the Request Queue within the project

Select Queue Details from the left-hand sidebar and make the following changes:

• Check to Publish as Request Queue
• Set request type to issue
• Uncheck all issue fields (we’re going to use our custom form instead)
• Uncheck the attaching of documents (not needed here, we’re going to attach our template to the project)
• Add the Statement of Work as a custom form
• Save the Queue settings

You should now have a queue setup that looks like the following image:

Before going any further, ensure your queue is functioning as expected.

• Go to the waffle menu in the top right-hand corner
• Click Requests

Select your new Statement of Work request as the Request Type and then fill out the form. You should see something like this:

Submit your request.

Go to your Request Queue Project and look at the Issues. It should appear like this:

Get very used to this request form… you’re going to be submitting it dozens of times when we set up the Fusion scenarios 😉

Next, you’re going to need a Word document marked up with some Document Generation and Sign tags for your Statement of Work template.

Here’s what our template looks like:

You can grab a copy at this link or feel free to make your own. Notably, this template has the following Document Generation fields in it…

• ProjectName
• ProjectManagerName
• CustomerFirstName
• CustomerLastName
• Message
• Tasks.Name
• Tasks.Duration
• S1_es_:signer1:signature

Save this document as StatementOfWorkTemplate.docx and upload it to your Statement of Work project in the documents section, like so:

We’re done with the pre-requisites. Let’s move on to building the scenario in Workfront Fusion.

Now we get to the fun part… wiring it all together! The following image is a snapshot of the first scenario that we’re going to build.

Create a new Scenario

• Log into app.workfrontfusion.com
• Select Scenarios from the left-hand side menu
• Select Create new Scenario button in the top right-hand corner

Add a trigger on a new request

The canvas will prompt you to add a new triggering module. We want to trigger the generation of our Statement of Work document when the request is made in Workfront. To do this, we need a new Workfront Trigger that listens for new issues.

From the list of modules choose Adobe Workfront and select Watch Events

• Add a new webhook and configure it as follows:
• Set Record type to Issue
• Set the Filter to DE: Customer Project is not null (This is the custom field in our SOW request form. The filter is how we isolate the new SOW issue events we’re interested in and ignore unrelated issues)
• Set Record origin to New Record Only

Side note: if you’ve authenticated your Workfront to Fusion connection using the same account that you use in the Workfront UI, you’re going to want to uncheck the “Exclude updates made by this connection” checkbox, otherwise the trigger will ignore you. If you’re using a dedicated service account for the integration — best practice — then you can leave the box checked.

Your webhook configuration will look like this:

You can now right-click the trigger object on your canvas and rename it to “On New SOW Request”

Your workflow now looks like this:

Fusion has great variable auto-completion features but to take advantage of them you need to run your scenario for the editor to learn what types of data each module generates as output. Let’s submit a request to our scenario.

Remember: If at any time during your scenario development you don’t see a particular field in the autocomplete, you need to run the scenario again to teach Fusion it exists. In our case, this means submitting a new Statement of Work request.

Run the Scenario

• Click the Run Once button to start your scenario.

Your scenario will now look like this:

In a new browser, tab goes to Workfront and submit a new Statement of Work request. (Remember how we mentioned you’d be seeing this a lot? here we go…)

Submit your request and return to your scenario. You should see some information in the log at the bottom of the screen, including “Scenario run was completed”. If this doesn’t happen, retrace the steps above to see where your configuration is incorrect. If the scenario ran, continue further.

Click the magnifying glass above the trigger to inspect the data that was received by the webhook.

Note the custom fields (prefixed by “DE:”) that were submitted with our issue. We’re going to use these in our scenario. Also note the format of the “DE:Customer Project” field — it’s a JSON object, not just an ID string. This is how the Lookahead custom field type stores data; all this means that we’re going to need to parse the project ID out of it before we can use it.

Parse the Customer Project field

We’ll use Fusion’s JSON step to parse the Customer Project field to turn it into something we can work with. We’ll create a Data Structure so Fusion can recognize it later in our scenario.

• Add a new JSON module of the type Parse JSON

• Click the add button to add a new data structure
• Click the generator button

• Copy and paste in the following JSON

“objCode”:”PROJ”, “name”:”Technology Conference”,”ID”:”61dcafd7001b997529ea19024d701c93″

Note: The values aren’t important, it’s the syntax that counts.

• And then Save again to complete the data structure setup.
• Set the JSON string to DE: Customer Project from the trigger step.

• Right click, rename your JSON object to “Get Project ID”

Filter the Requests

We want to ensure that only requests with an existing Customer Project are permitted to run through the workflow. This should be handled already by the trigger, but it is still good practice to enforce here.

• Click the wrench between the Workfront trigger and the Parse JSON module
• Click Add a Filter
• Set the Label to Project ID Exists
• Set the first field in the condition to new state:DE:Customer Project from the Trigger module
• Set the condition to Exists
• Click OK

Get the project tasks

From the DE: Customer Project field we know what customer project was mentioned in the Statement of Work request, so let’s query for it.

• Add a new Workfront module of the type Read Related Records
• Set the Record Type to Project
• Set the Parent Record ID to the ID on the Get Project ID module
• Set the Collection to tasks
• Select the Name, Duration, and Status fields in the Outputs (of course you are free to return as many fields as you need for your scenario, we’re just using the very basics for our example)
• Save the module
• Rename the module to Get Project Tasks

Your scenario now looks like this:

Since the Get Project Tasks module is going to introduce new data structures into our scenario, you’re going to need to re-run it for the fields to appear in the autocomplete.

• Save your scenario (disk icon in the bottom toolbar)
• Click “Run Once” to start your scenario
• Go to the request queue in Workfront and submit a new SOW request.
• Ensure the scenario has run correctly, and correct any errors.

Transform the task results into JSON

For reasons that are a bit longer than we want to get into here, we need to transform the output of the Get Project Tasks module into one that we can use downstream when we use them in the Document Generation module. The TL; DR is Fusion’s internal array structure isn’t the same as the one that Document Generation uses, so we need to transform it. We’ll use an Array Aggregator in the Tools module to do this.

• New Tools module of type Array Aggregator
• Set the Source Module to Get Project Tasks
• Set the Target Structure Type to Custom
• Set the Aggregated Fields to duration, name, and status.

Get project information

We know the ID of the project from the Issue, but we don’t know much else about it. Let’s get the project name and description from the project record to use in our template.

• Add a new Workfront module of type Read a Record
• Set the Record type to project
• Set the ID to the ID that was parsed in the Get Project ID module
• Set the Outputs to Name and Description
• Right click and rename the module to Get Project Details

Your new module should look like this:

Get the project manager’s information

Our template has a space for the email and name of the project manager who generated the Statement of Work. We’ll look at the issue object and read the user details of the person who submitted it.

• New Workfront module of type Read a Record
• Set the Record Type to User
• Set the ID to the newState:enteredByID in the trigger step
• Set the Outputs to Email Address and Name
• Rename the module to Get User Details

Your new step should look like this:

By now we’ve got all the information we want to put into our template: our recipient information (from the issue object), our project tasks descriptions (from the project object), and the information about the requestor (from the user object).

Get the template

Now we will locate and then download the template from our request project in Workfront into the Fusion scenario.

• New Workfront module of type Read related records
• Set the Record Type to Project
• Set the Parent Record ID to newState:projectID on the trigger module. (Remember: the template is in the request project, not in the project we’re generating the SOW for)
• Set the Collection to Documents
• Set the Outputs to ID and Name
• Rename the module to Find Documents

Your new step will look like this:

• Add a new Workfront module of the type Download Document
• Set the Document ID to the ID in the Find Documents step.
• Rename the module to Download SOW Template

Important: It’s possible that in the future more than one Document could be inside your request project. We need to filter the results that come from the Find Documents step to ensure only the template is downloaded.

• Click the wrench between the Find Documents and Download SOW Template modules.
• Click Set up a Filter
• Set the Label to SOW Template Only
• Set the condition to name (from the Find Documents step) starts with StatementOfWorkTemplate (or whatever you named your template)

Your filter will look like this:

Now would be a suitable time to start your scenario and run it by submitting a new request into your SOW queue.

Generate the Statement of Work PDF

We’ve got the data, we’ve got the template, let’s generate a document!

• Add a new Adobe PDF Services module of the type Generate Document
• Set the Source file to the Download Document step
• Set the Output Format to PDF

We will map the fields from the various scenario modules into the keys to be used in our document template. The Key should be written as it appears in the document template.

The customer fields come from the initial trigger module:

• CustomerFirstName to newState:DE:Customer First Name
• CustomerLastName to newState:DE:Customer Last Name
• customer email to newState:DE:Customer Email
• Message to newState:DE:Note to Customer

The project manager fields come from the query user module:

• ProjectManagerName to name
• ProjectManagerEmail to emailAddr

The project fields come from the query project module:

• ProjectName to name
• project description to description

The tasks come from the Prepare Task JSON module we used to transform the results of the tasks query.

• Set Tasks to Array[]. Note also to set the Value type to Array

Your PDF Services module will look like this:

Your scenario should now look like this:

Click Run Once to start your scenario, go to Workfront and Submit another SOW request. Your scenario should run to completion.

Send the Document for e-Signature

Sending the document to the recipient happens in two steps: uploading the PDF to Acrobat Sign API as a transient document, then instructing Acrobat Sign to send the transient document to the recipient.

• Add a new Acrobat Sign module of the type Upload Document

Note: If you have not already instantiated a connection to Acrobat, do so now by clicking Add, and follow the prompts. Use the Acrobat Sign developer account referred to in the prerequisites.

• Set the Source file to the output of the Generate Document module
• Save the module
• Rename the module to Create Transient Contract

Your Create Transient Contract module should look like this:

Now you need to send the document to the recipient for e-signature.

• Add a new Adobe Acrobat Sign module of the type Create an Agreement
• Add a new item in Files to Send. Set the type to Transient Document ID and the Transient Document ID to the body:transientDocumentId of the Create Transient Contract module.

• Set the Agreement Name to Statement of Work.pdf
• Set the Signature type to E-Sign
• Set the State to In Process
• Add a new item to the Participant Sets
• Set the Email to the new state:DE: Customer Email of the trigger step
• Set the Name to newState:DE: Customer First Name newState: DE Customer Last Name (sorry for the formatting in the article — when you’re setting it up just click the first and last name fields one after another to add both fields)
• Save the participant set

• Click the Show Advanced settings checkbox at the bottom of the dialog box and then scroll down in the dialog until you see the External ID field.
• Set the External ID field to newState:ID from the trigger step
• Save the module
• Rename the module to Send for Signature

Before going any further let’s explore why we’re using the External ID.

As mentioned earlier, we need two scenarios — one for sending the document to the recipient (this one), and the second scenario for updating our project once the document is signed.

External ID is used in Acrobat Sign to let developers link a Sign transaction with an ID in another external system. In our case, we will link the issue ID of our SOW request issue with the Sign transaction.

When Sign sends Fusion a webhook trigger that a document has been signed it will send along the External ID. We then will look for SOW requests that match this ID, so we know which statement of work request the incoming signature notification is for.

Update the SOW request issue status

Now we will reflect that the document is out for signature by updating the status of the request to “Awaiting Feedback”. We’ll do this with an Update Record module.

• New Workfront module of type Update Record
• Set the ID to the newState: ID of the trigger module
• Set the Status in Fields to Map to Awaiting Feedback

Move the request issue to the customer project

Finally, we want to put the SOW request issue in a place our project team will see it — on the issue list of the customer project.

• New Workfront module of type Misc Action
• Set Record type to Issue
• Set Action to Move
• Set ID to newState:ID from the trigger module
• Set project to ID from the Get Project ID module
• Rename the module to Move the issue to the customer project

Congratulations! You have completed the first scenario. It should look like this.

Run the first scenario end-to-end

Note: Now that you’re submitting a document to Adobe Acrobat Sign it is important to use a valid destination email address you control as your recipient so you can receive and sign the document during testing.

• Click Run Once in your Scenario
• Go to Workfront and Create a new Statement of Work request.

• Submit your request
• Watch your scenario in Fusion to ensure it runs to completion

If you look at the Issues tab in your customer project, you will see your issue. Note the status. Team members can look here to understand where in the signing process the Statement of Work document is.

• Open your email client and check the Inbox of the recipient address
• Look at that beautiful Statement of Work signature request 🙂

• Click Review and Sign (Note: you may need to copy the link and open it in a second incognito browser, as you may already be authenticated into Adobe Acrobat Sign using the developer account. You won’t be able to sign the document otherwise.)

Scroll down to see the details and the completed template.

Now sign it!

Congratulations!

You’re now able to generate and send a Statement of Work document using Fusion, PDF Services, and Sign APIs by filling out a request form.

We have now completed the construction of our first scenario. Before we continue to the next scenario, we need to ensure this one is always-on so it will respond to all new statement of work requests.

• Go to your scenario
• Turn the scheduling switch to ON

Let’s move on to the second scenario: receiving signed documents.

We want Workfront to update when our customer has signed the document. Adobe Acrobat Sign can send webhook triggers to Fusion when a signing event occurs. We’ll use this trigger to initiate our scenario.

• Set the trigger to Adobe Acrobat Sign module of type Watch for Events
• Add a Webhook
• Set the Webhook Scope Level to User (note: this is the user that is authenticated in the Sign/Fusion connection, not the user of whomever is submitting the SOW Request form, which may be different)
• Set the Webhook subscription events to Agreement Workflow Completed

This trigger will fire when any agreement sent by the integration user account has been signed.

Read the agreement details

Before continuing to add modules, we must run the scenario to ensure that the trigger is functioning correctly.

• Submit a new SOW request
• Set your scenario to Run Once
• Sign the SOW document
• Confirm that the scenario was triggered
• Inspect the output of the trigger by clicking the magnifying glass next to the trigger module.

You can see that the trigger contains only minimal useful information about the document that was signed — the ID of the document, some signer information, and the filename.

Query the Adobe Acrobat Sign API for more agreement information

We need to know more information about the document that was signed, namely, its External ID, to know if it’s one we’re interested in for our scenario.

• Create a new Adobe Acrobat Sign module of the type Read a Record
• Set the Record Type to Agreements
• Set the Record ID to the Agreement:ID from the trigger module
• Rename the module to Read Agreement

You’re going to need to run the second scenario again to hydrate Fusion’s metadata autocomplete.

• Submit a new SOW Request
• Start your scenario to Run Once
• Sign the SOW document
• Verify your second scenario has run correctly

Retrieve the Signed document

At the time of authoring this article the Adobe Acrobat Sign module for Workfront Fusion does not yet have a native “Download Document” action. That doesn’t mean we can’t do it; we just need to be creative. Fortunately, there is a Custom API Call action that we can use to call any Adobe Acrobat Sign API endpoint.

• New Adobe Acrobat Sign module of type Custom API Call
• Set the URL to /agreements/<agreement:id>/combinedDocument?attachAuditReport=true
  Note: Setting this combined value field (placeholder and text) can be a bit finicky. Try adding the agreement: id from the field picker first, then type in the URL portion on either side of it.
• Rename the module to Download Agreement

Your download agreement module will look like this:

Once again, submit your SOW request, start this scenario to Run Once, sign the document, and watch the scenario run to completion. We promise this will be the last time you need to do this before we finish building the scenario.

Filter the results

Remember this scenario runs for every signed document. Let’s constrain our scenario so that only the Statement of Work documents are processed. Placing a filter between the Read Agreement and Download Signed Agreement modules will do this.

• Click the Wrench on the connecting line between the Read Agreement and Download Agreement
• Set the Label to Signed with External ID
• Set the Condition to an agreement:status (from the trigger) equal to SIGNED
• Add an AND rule
• Set the body:external to Exists

Only documents that have External IDs (which we set up as the issue id in the first scenario) can now proceed past the filter.

Save the signed Document into Workfront

We will now place the signed Agreement into Workfront, attached to the Statement of Work issue inside the customer project.

• Create a new Workfront module of the type Upload Document
• Set the Related Record ID to the body:external: id from the Read Agreement module
• Set the Document Name to Signed Scope of Work[<now>].pdf. (You can find the <now> placeholder on the Date and Time tab of the variable list.)

• Set the File Content to the Body from the Download Agreement module.
• Save the module
• Rename the module to Save SOW Document to Issue

The save SOW document to issue module now looks like this:

Update the SOW request status to Closed

Last step! We need to change the SOW request status from ‘Awaiting Feedback’ to ‘Closed’ to signify that the process is complete.

• Add a new Workfront module of the type Update Record
• Set the ID to body:external from the Read Agreement module
• Set the Record Type to Issue
• Select the Description, Percent Complete, and Status fields from Select Fields to Map
• Set the Percent Complete to 100
• Set the Status to Closed
• Set the Description “The document has been signed by body:participantSetsInfo[1]:memberInfo[1]:name (body:participantSetsInfo[1]:memberInfo[1]:email) at body:lastEventDate” with all three of the tokens coming from the Read Agreement module.
• Rename the module to Resolve SOW Generation Issue

Your final module should look like this:

And your scenario should now look like this:

• Turn the scenario’s scheduling to ON

We’re all set! Let’s step through our new automated Statement of the Work process from end to end!

Here’s the customer project that we will generate a Statement of Work:

• Go to the Waffle menu (top right)
• Select Requests

• Fill out the subject, Customer Project, name, email, and note fields.
• Submit the request
• Navigate to your customer project
• Select the Issues tab from the left-hand navigation
• Note the presence of your request, and its status is “Awaiting Feedback”

• Open the inbox email account associated with the recipient of your Statement of Work document.
• Click the Review and Sign link

• Sign the Statement of Work as the recipient.

• Navigate to Workfront and refresh the issues screen of your customer project. Note the issue status has now changed to Closed.

• Click on the Documents tab, and note the presence of the signed Scope of Work document attached to the project.

Congratulations! You have successfully automated what used to be a time-consuming, tedious multi-step manual process involving four separate tools (Word, Workfront, email, and Acrobat Sign) and turned it into a highly streamlined, zero-effort, automated experience!

We hope that this article has given you both the inspiration and confidence to tackle some of your automation use cases.

If you’d like to download the final scenario blueprints or the document template, check out the supporting assets on GitHub.

You can enhance your Workfront Fusion knowledge by exploring the documentation, or by following the Fusion learning path on Experience League.

Finally, if you’d like to learn more about some of the diverse ways you can work with your documents using Adobe PDF Services, please check out the documentation, and if you have questions, please pose them in the community.