Building custom UIs for Workfront with Fusion

[#1]

As implementer or Workfront admin, have might have come across an ask that that you just can't realize in core Workfront. For example, you can't display the Documents of all child projects at the Program level (you see the files attached to the specific program). Sometimes WF Reporting just doesn't offer what you'd need. 

Here's a way to leverage Fusion to create an external page that can be accessed in a WF custom dashboard. With this approach you could implement the "impossible" asks. [Apologies in advance: This will feel like web tech from ~2000] 

This is not something I invented - and it was the examples I saw from my colleagues at IBM iX that got me thinking. There were a handful of cases where I wanted a tool that pulled data from the Workfront API and presented it to me visually instead of just the raw API output. After tinkering with this I ended up with an approach I keep coming back to. It emulates what an app server might do (receive a request, look up some data, maybe do some number crunching, and return an HTML page as response). 

Examples

A custom dashboard for programs to list documents from all projects under this program. Adding a checkbox next to each item allows selection and posting e.g. the IDs to another scenario for processing.	A standalone dashboard to backup project templates to XLSX. The template backup can e.g. be uploaded to a Workfront project, where each template has its own task. Backups can be stored as document versions, or simply as date-stamped files.
Not my work, but an example what a simple milestone report could look like.	More involved example of a scenario backup manager that stores a scenario backups in data stores with version comments and the ability to restore an arbitrary version

Approach

A dashboard can be populated with an "external page" that is, any URL that allows itself to be i-framed. Here we use Fusion's webhook URL. As soon as the page loads, the webhook is called, Fusion does its thing, produces output and sends it back. The browser then displays that page. 

So I'm basically frankensteining Fusion into an app server of sorts. All the Fusion caveats (e.g. delay in response) apply, but for a lot of purposes this is performant enough. 

So what do we need in this scenario? 

1. Webhook - it gives us a URL we can put into the Dashboard
2. Modules that create the output HTML/CSS/JS
3. Webhook response - to send the HTML back to the browser

Here's what this might look like (JSON.zip attached below)

After the webhook module (which gives us a URL), we set multiple variables: 

1. CSS
2. Javascript
3. HTML body content

The set-output module is our "outer template" - the page boiler plate. Here you could add anything that's common to every page. You can see the JS/CSS/HTML variables here.

The Deflate module compresses the HTML for a marginally faster delivery - a good habit but doesn't really make a difference until you send a page with lots of content. 

Finally, the webhook response module. Without it, the scenario will just return the text "Accepted" immediately after it gets the request. Using this module keeps the connection open, meaning the browser waits for a proper response. 

The status = 200 to tell the browser all is well (i.e., no error); the body is the populated value of the "set output" module. The headers let the browser know exactly what we're sending: The response is an HTML document that was compressed.

Now save this scenario, enable it, and open a new tab and paste in the webhook URL. You should see something like the below. (The "animation" is Javascript that runs after you click the button). 

Why even do this?!

If you're at all familiar with how web apps are built, this will feel - hokey. It is. But in the end, your browser doesn't care who sends the webpage. 

My reason for using this approach are:

1. It works well enough
2. I can move some logic from Fusion into the web app (using Java Script)
3. It's quick - no server set up etc. - it's just Workfront & Fusion
4. It opens so many possibilities - whether it's a tool that saves time, or a custom page that displays what you otherwise could not
5. Because we're in client-land (the page "runs" in the client, ie, the browser) you can pull in jQuery or any other tool you like.

But...

I'd be remiss if I didn't address some caveats. 

• Fusion isn't a speed demon (Actually the execution is usually speedy, but it may take a few beats for a scenario to start running.) and such a custom page may take a few seconds to load. 
• Due to Fusions no-code interface, some data manipulation might seem more onerous that if you just wrote a Python script
• You're stuck with data stores, variables and the Fusion modules - there's no docRoot, no folders or templates 
• There's no no user authentication. If you want to limit who can access the endpoint, you'll need to use Workfront as "authentication" mechanism
• You have to think through how to present the data - validation, pagination, forms, the whole UI - needs to be written (but you can pull in any JS libraries from a CDN). 

So yes - it's a bit raw, but worth trying out. It may not fit your use case. But maybe it does? Let me know! 

edited: Typos.

Further Reading: (when I've written them)

• Let's use some Workfront content (Program documents)
• Generifying the "app server" pattern
• Routing: Adding XHR calls
• Securing the custom dashboard

HTML page with Fusion.zip ‏2 KB