Expand my Community achievements bar.

Enable Fusion reporting directly in Workfront

Avatar

Community Advisor

We recently adopted this best practice and I thought I would share with the community. 

Sometimes, a problem surfaces with a Workfront record in which its clear that Fusion did not create or update the record in the expected way. When this happens, it can be time consuming or impossible to track down the specific execution so you can inspect the module inputs/outputs.

With that in mind, we started recording the scenario ID and execution ID to Workfront records as part of the create or update Workfront record modules in every scenario. Having these IDs as part of the Workfront record itself enables you to create Workfront reports that can:
1. Open the actual execution that created a record.
2. Open the actual execution that last updated a record (which may be different than the scenario that created it).
3. Count, filter, and group records that are created or updated by Fusion, by each scenario.

This enables you to answer questions like:
"This record doesn't look right. What did Fusion do to it?"
"How much time did Scenario X save us in total?"
"Which scenarios have the most (or least) usage?" 
"Which project owners benefit the most from Scenario X?" 
or anything else that requires you to associate Workfront records to the Fusion scenario(s) that acted on them. 

To enable this, you need dedicated fields on every object's form(s) to which you can record a scenario ID and an execution ID. Each of these fields are needed twice: once to record the scenario and execution that created a record (POST SID and POST EID), and an other to record the scenario and execution that last updated the record (PUT SID and PUT EID).

The scenario ID can be hard-coded in modules, but I prefer to set it as a variable as the first step in a scenario. 
The execution ID can be found in the General Functions tab.

Once you start recording this data, you can design any number of Workfront reports that use the IDs to inform you of relevant Fusion actions. Screen captures attached to show step-by-step actions to enable these features.

1. add fields to forms.png2. set scenarioID.png3. find executionID.png4. create record.png5. update record.png6. add view columns.png

Good luck and enjoy!

If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf
4 Replies

Avatar

Level 6

completely agree this would be helpful if the system managed in a way for us.  We're doing something similar on our integration with Salesforce.  We have several scenarios that make updates and we needed a way to identify which of them made the update so we could track back errors.

 

Thank you for documenting the above!

Avatar

Level 3

This is fantastic. Thanks for sharing!

Avatar

Level 9

@William--  I'm looking to implement this in my Workfront instance. How do you handle it if there are multiple times Fusion touches a project? 

Avatar

Community Advisor

Hi Kimberly, 

We opted not to keep a full log of Fusion executions on the Workfront record, because some records are updated daily or more. We only track the execution that created the record (if applicable) and the execution that most recently updated the record (if applicable.) So, the prior PUT executionID is always overwritten. 

If having a full history of PUT execution IDs is critical, I suggest adding an additional field, "SYS Fusion Log." At the beginning of every scenario, read that value from the record. Have the scenario do it's thing, then at the end, append the prior value of "SYS Fusion Log" with the URL of the current execution. This will result in a clickable list of all executions that touched the record. 

-WE

If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf