Workfront Fusion scenario optimization

What is “scenario optimization” and what can you do to optimize your scenarios?

Scenario optimization is a practiced skill that takes time and dedication to develop. Your first attempt at building a scenario for a business outcome should not be your last. Scenarios should be iterated upon from day one until your integration is launched. Even after you launch, scenarios should be reviewed and updated throughout their lifespan to keep up with business and behavior changes.

Scenarios require maintenance. Workfront Fusion developers should have a regular cadence of reviewing scenarios for opportunities to rebuild, restructure, or optimize. Workfront Fusion scenarios need regular attention, upkeep, and maintenance.

In this video, you will learn how to:

  • Perform fewer operations
  • Send fewer API calls
  • Use fewer modules
When it comes to fusion less is truly more, complexity can be the killer of continuity and doesn’t deserve a high five. Antoine de Saint-Exupery is quoted for saying “Perfection is achieved not when there is nothing more to add, but when there’s nothing left to take away.” At Workfront when designing scenarios the number one goal is to iterate on the scenario design making it as simple as possible. Let’s take a look at three lessons or ways that you can work simplicity into your design approach. First, focus on performing fewer operations throughout your scenario. When we process bundles of data through fusion, each bundle passed through is considered an operation. Fewer bundles means fewer operations. You can determine the number of operations performed in each module by looking at the number in the bundle inspector. To reduce the number of operations you can either filter or aggregate. In some cases, you can even filter the bundles outputted from the trigger module. For example, on the Workfront search module you will find search criteria which allow you to filter before bundles even enter your scenario. If using a trigger module that doesn’t contain filtering criteria, placing a filter right after the trigger is another great way to reduce unnecessary operations. Another technique for reducing the number of operations is to aggregate your bundles whenever possible. Remember that each bundle of data passed through a module is considered an execution. So aggregating multiple bundles of data whenever possible will reduce the number of bundles passing through a module. For example, it’s relatively common for a project use case to require working with a project record itself and the project’s tasks. A scenario should only perform a project’s operations once and not for every task found related to the project. An aggregator makes it possible to only process the multiple task bundles in an iteration, and only the single project bundle outside of the aggregation. The second way to optimize your scenarios is by reducing the number of API calls made to your third party systems. Fewer calls made to external APIs not only prevents risks of hitting rate limits causing errors in your scenario, it will also keep your scenario running as efficiently as possible, reducing the execution time per run. Every time you make calls to another system it taxes that system, so it is wise to only make as many calls as you need. To reduce the number of calls, you can use filters to create very specific triggers or only read, post, or put for relevant records. Similar to the strategy to reduce the number of operations using filters appropriately will reduce the number of times external APIs are called and how many actions you’re asking it to perform. When considering your scenario design you may also gather data on records earlier in your scenario to be used in multiple paths. Doing this helps avoid having to call the external systems APIs in each path to get the information needed. Finally, if needing to gather multiple pieces of information on records passed through your scenario consider using the advanced settings and modules, which allow additional information to be gathered from reference objects or collections. Additionally, you can structure your call using the custom API, reducing the number of modules needed. Here’s an example to highlight what’s possible using the Workfront custom API call. After the initial trigger, pulling in updated issues, we use a single module to confirm the right bundle of data is passing through. Get information on the custom form and documents connected to the issue, and finally, find some related project data. To learn more about Workfront’s API specifically and what references or collections are available on certain object types, make sure you visit the Workfront API Explorer page. Our third strategy for optimizing your scenario design is by having fewer modules. Think about how Apple took a computer and eventually got to the iPhone. They made a large computer smaller and smaller, until it’s a phone in your pocket. Take the same strategy with your scenario design. Create what you need to make it work, and then step back and think how and where can you reduce the size of the scenario and the number of modules used. While there is no cap for the number of modules in a scenario, scenarios with more than 150 modules negatively impact the performance of your Workfront fusion system. To get good at reducing the number of modules in your scenario, start by mastering the mapping panel. Try to go through all of the functions in each area and learn to use each. Understanding how each function or formula behaves will open up doors to using the better expressions rather than creating more modules to do the same action. Another strategy is to find areas where you can use the Set and Get variable modules, especially the Set and Get multiple variable modules. Not only will this prevent the need for extra modules, it will also support having fewer operations and making fewer API calls if you’re passing needed data between paths, rather than calling your third party systems in each path for the same data. As mentioned already, find ways to get data needed throughout your scenario, earlier in your scenario design, to avoid redundant actions. Finally, get comfortable working with arrays and collections. Doing so will open up doors to create expressions to gather the data needed, without having to use multiple modules to pull and then manipulate that data. Implementing these three optimization strategies of having fewer operations, fewer API calls, and fewer modules, requires practice in an iterative approach. Typically, your first design of a scenario will be inefficient. Throughout the design and testing process. You’ll want to go back multiple times to refine and make your scenario as efficient as possible. If you correctly identify the input and output of your scenario. Think, how do I get my input data to match the output that I want? Think in terms of bundles to be able to better visualize the data manipulation that’s needed. Putting in the effort here will reduce the number of errors experienced, increase the speed in which your scenario executes, avoid any performance guardrails, and ultimately makes you a better fusion designer. -

Want to learn more? We recommend the following:

Workfront Fusion documentation