Define distinct use cases and find the best approach

When starting with fusion, you should focus on selecting and defining the use case first. You’ll want to avoid squeezing multiple use cases into one scenario because scenarios lose performance when the use case is trying to do too much. Consider this analogy. If you wanted to enter the Tour de France and are presented with the following two bikes, which one would you choose from to efficiently make it to the finish line each day? Sure, the touring bike with saddlebags and extra equipment might have something ready for any situation. However, it’s going to take a lot more effort to get to the finish line and potentially, that will mean more chances of flat tires, getting stuck in bad weather, et cetera. You get the idea, obviously, you’d want to buy the lightest, leanest bike you can afford because your goal is to ride as efficiently as possible. The same idea applies to your fusion scenario designs. The more complex you make them, the more likely they’ll run into issues. So, how do you avoid having your scenarios do too much? You can do this in a variety of ways but consider these two primary strategies. First, before you start developing your scenario, determine a single use case. Start by really trying to understand the single trigger event that will activate this automation. Ask what happens when someone is working that will trigger the event and therefore, trigger the scenario. The best trigger events are the ones that are well-defined and specific. An unrefined trigger event should be a warning sign that not enough time was taken in discovering what specifically should trigger the scenario. This will result in unnecessary data running through the scenario, decreasing performance, and possibly increasing the chance of errors. Think about this example of a specific versus a general trigger. A fusion user could trigger the scenario every time a specific task field such as status is updated versus having the fusion scenario go in search for all tasks every hour for changes in status. Obviously, the first option is more specific and will return only the necessary information to be processed in the scenario, making for a more efficient setup. If you remember from earlier in the training, there are two types of triggers and fusion. Instant triggers are event-driven and are typically better in designs because of the relation to work processes and activities occurring in systems. You’ll know which modules support instant triggers because of the instant label next to the module’s name. When using these types of triggers, you’ll also notice a lightning bolt instead of a clock on the trigger module when used. With scheduled triggers, you should ask more critical questions of your design if the frequency of the schedule is high, for example, every five minutes. What is the business driver for this frequency? Would a real time trigger be better? Or maybe we don’t need an update every five minutes and a daily or overnight update would suffice. Additionally, scheduled scenarios that start with a search module are generally not the best triggers and might be a sign of an ambiguous understanding of the work process and the specific trigger needed. A final consideration to keep in mind is the difference between scheduled watch record and search modules. Watch record goes out and looks for changes, accounts for records already processed, and does not process them again unless manually performed by choosing where to start. Search modules will do the same search every cycle not just looking for updates or accounting for records already processed. All of this does not mean that you should never use scheduled triggers. Just that fusion users should be aware of the consequences of each trigger type and carefully select the right type for their use case. Another suggestion for making sure your scenarios aren’t trying to do too much is to always be on the side of right design. Sometimes, that means spending more time in discovery to make sure that specific and clear trigger are identified and that the right use case is mapped out. At other times, it will mean making decisions on what data should be transferred in sync between systems. Lastly, there will be times where you’ll need to work with your account rep to make sure you’ve got the right fusion setup to handle the use case you want to run optimally. Making sure you find the best approach to your automations will keep them running optimally and make sure that they’re easy to maintain long-term. As a final note, be sure to step back and make sure you’re challenging assumptions and giving advice to your stakeholders from the perspective of the best solution. Typically, they will want to have fusion be the magic tool that does everything that they need. For example, some people will want fusion to manipulate data to match the desired output on a report but you should be using a reporting tool for this. The better solution is to use fusion to pull data from a system and put it into a data lake for reporting systems to pull from. Another example would be a request that fusion, take a CSV export with a variable number of columns in different data types, all submitted to the system in different ways by managers. It could take hundreds of hours to figure out the immense amount of logic to account for all variability. Instead, it would be better to approach that situation by having a conversation with the business about the change management required to get all managers following a consistent spreadsheet supported by the solution that fusion can efficiently provide. You always want to build scenarios that can handle the long-term, whether it’s through simplifying the design, focusing on specific use cases, making sure your trigger targets the the right kickoff to your scenario, taking the time needed to adequately understand the use case, and finally, challenging stakeholders to give them the best advice and approach. -