Workfront

Christopher29269095dwjg · 6/10/24

Hello Workfront Community,

I am currently working on a project where we'd like our marketing team to use Workfront to submit requests for data via custom forms. These forms include various custom metadata fields such as "Product," "Need by Date," and other contextual information relevant to each request.

Our goal is to automate the creation of JIRA tickets based on these Workfront form submissions, ensuring that all relevant custom metadata fields are accurately transferred to JIRA alongside the standard fields supported by the native Workfront to JIRA connector.

I have a few specific questions:

Custom Metadata Field Integration: Does the native Workfront to JIRA connector support the integration of custom metadata fields, or is it limited to standard fields only? If custom fields are supported, how can we set up this mapping?
Best Practices and Tools: For those who have tackled similar integration challenges, what tools or middleware solutions (e.g., Zapier, Workato) have you found effective? Are there any specific best practices or pitfalls to be aware of?
Alternative Approaches: If the native connector does not support custom metadata fields, what alternative approaches would you recommend? Has anyone successfully used Workfront and JIRA APIs for this purpose, and if so, could you share some insights or sample code?

I appreciate any guidance or experiences you can share on this topic. Thank you in advance for your help!

Rafal_Bainie · 6/11/24

I haven't used Jira cloud connector myself, but I took a look and it seems that workfront custom data if it can be imported to custom fields in Jira than only via custom API call module.

if wf's custom data is targeted to native jira fields you may be able to do that with update record module

hope this helps

KatherineLa · 6/11/24

I was unable to use the native connector because Support said it required granting the Jira side of the integration full administrative access to WF which I don't allow platform integration accounts to have for a long list of security reasons and hard-earned paranoia. I am currently working my way through an integration with Fusion instead.

That project is going mostly well. It supports connecting both native and custom metadata fields, though I do have some concerns about stability with things like constrained picklists changing on one side but not the other. That would be true regardless of the integration method though. I do like that it's very easy to see all the Jira fields, which are required, what the options are in the drop-downs right within the Fusion UI.

I did briefly experiment with the 'External Lookup' fields to see if I could get the drop-down options in WF to populate from Jira directly to ensure all the options were the same on each side. There I did run into an issue with the Jira API not exposing certain options for certain types of Jira-projects. Unfortunately those were exactly the type our Jira instance happened to run.

Happy to elaborate more if you have questions.

Christopher29269095dwjg · 6/11/24

Thank you for your response @KatherineLa ! This is very helpful. So to confirm, you have created custom metadata for users to complete in WF and custom metadata fields in JIRA for WF to then populate once the request has been completed. To do this, you are using a fusion flow to complete the process? If so, makes sense!

Does this integration support bi directional communication / commenting on the ticket itself, while still allowing marketers to stay in WF and data providers / IT to stay in JIRA?

KatherineLa · 6/11/24

At the moment, we're just about done with the initial Jira Issue creation portion, where a Request in a monitored WF queue is detected by Fusion and all native data, custom fields and documents uploaded in WF are being successfully received in Jira. In our instance, I've got 5-6 queue topics that need to map to different projects/issue types in Jira also.

With respect to bi-directional communication, we haven't begun to build it yet, but here's my Plan A:

Workfront to Jira - When the WF issue is originally sent to Jira, one of the steps the scenario does is to complete the External Ref ID to create a clickable link to the corresponding Jira ticket. That gives me the ability to train a second scenario to watch for Updates to an Issue record where the External Ref ID is to a Jira ticket.
- Assuming I can isolate those record changes the way I expect, then I should be able to push a field sync over to Jira with those updates. I know I can make a comment in Jira through the sync, but Jira (at least my instance) doesn't thread conversations the way WF does so that part may be ugly. That covers my Marketing team sending info to Dev (my use-case is the same as yours). Document sync should work similarly.
Jira to Workfront - This half is less clear. There doesn't seem to be an External Ref ID function in Jira, and I haven't found a good way to isolate what records were created by the sync. I may ultimately ask the team who manage Jira to create one for me on these issue types, or maybe they'll find something I haven't yet. Once we determine that part, I'll train another sync scenario to watch those Jira issues for updates, and make corresponding updates in WF.

I do NOT plan to support deletion over the sync, either of documents or the Issues on either side. Generally I don't allow automations to delete things, I've seen it go haywire in vendor integrations more than once.

We also haven't discussed which fields SHOULD be modifiable by either side, and if there are any key sensitive fields where both parties should be agreeing on changes before they just happen. That's Future Me's headache.

KIMBERLYREA · 7/23/24

How many different scenarios did you use for each direction? Do you have updates going from WF to Jira immediately or on a frequency?

KatherineLa · 7/23/24

What is currently live is a single scenario that watches for new Issues in a specific queue and immediately raises a paired Issue in an appropriate project for Jira, then copies over all the custom fields and documents. At this time, we've decided not to allow WF updates to push to Jira to avoid change management/scope-creep chaos. If at some point we allow a limited version of this, maybe to allow additional documents or comments across, I believe I could do so within the existing scenario.

Also at this time, we aren't going to have changes in Jira push back to Workfront either, but that's mostly due to other org priorities. We're going to initially train the WF-requestors that they are responsible for closing out their side of this issue as a way of saying they've accepted the work as complete. Eventually I will, if only to allow the Jira issue to close the WF one at the same time as we scale up. That will take one more scenario to watch the paired Issues in Jira. In that scenario, my plan is to have that sync happen on a set frequency to avoid performance impacts on either side and allow the scenario to only poll the appropriate Jira projects/issues rather than constantly watching and evaluating all changes instance-wide.