In this article, we are going to go over guidelines and best practices of using the Launch Console when designing a Wrkflow. For an overview of the Launch Console, see this article.
The main purposes of the Launch Consoles are:
Showing launch progress
Consuming Wrkflow outcome
Debugging Wrkflow and monitoring errors
As with every guidelines and best practices, you can choose to follow them or not. As a Wrkflow designer, it is up to you to decide how to make use of the Launch Console. The Wrk platform is a tool for you to design your automation process and it doesn't know what your Wrkflow is meant to achieve as well you do. The purpose of your Wrkflow will dictate the goals of using the Launch Console and those goals can vary drastically from one Wrkflow to another.
Showing Launch Progress
Quality over quantity
Quality over quantity
While there is no limit to how much progress updates you can send to the Launch Console, there is however a limit to how much information a user of the Wrkflow can consume from the progress window. A large and complex Wrkflow can potentially process tens of thousands of updates a minute. If all of those updates are sent to the Launch Console - a user who is watching the progress of the launch will only see a small subset of the updates at a time.
There is one size fits all when it comes to how much information to send to the Launch Console, but below are general guidelines:
Send to Launch Console at inflection points in your Wrkflow rather than sending to Launch Console at every step of a Wrkflow. Inflection point can be that a key piece of data was capture by the Wrkflow, a modification was made to a 3rd party system, a branching occurred in the Wrkflow, etc. Mundane steps are generally not worth sending to the Launch Console.
There is no need to denote the start or end of the Wrkflow as the system will automatically send the start and end to the Launch Console.
Short Wrkflows require less frequent updates to the Launch Console as it is expected to end quickly.
Long multi-Wrk Actions Wrkflows on the other end will likely benefit from more updates to show progress over time as the completion of the launch can be longer. Complex and long Wrkflows can potentially take days to complete and regular updates is beneficial for those Wrkflows.
Differentiated updates with dynamic content
Differentiated updates with dynamic content
To make the updates relevant for a user of a Wrkflow, differentiate between the updates that are sent to the Launch Console. For example, if there are hundredth of updates being made to Asana and the update being sent to the Launch Console is too generic - "An update was made in Asana" - the user will be seeing hundredth of the same message in the Launch Console.
Use of dynamic content via the Data Library is highly recommended when sending information to the Launch Console. An example of a differentiated update to Asana - "The activity Complete project X was marked as Completed in Asana", where the text in bold are dynamic, meaning they will be different for each update that is done in Asana.
The order of the updates is not relevant to show progress
The order of the updates is not relevant to show progress
Other than the beginning and the end of a Wrkflow, the order of execution cannot always be controlled. The execution of a launch can branch and divide, which will put the narrative out of order.
Avoid displaying sensitive information
Avoid displaying sensitive information
The Wrk platform comes with measures to protect the data that is in transit during the execution of a launch. For example, data are encrypted and are not accessible to anyone until it is delivered to destination (e.g. data has reached a 3rd party system or delivered to destination via an email).
Sending data to the Launch Console makes it readily visible and available in the progress window. As such, it is recommended not to display data that is sensitive (e.g. bank information, personally identifiable information (PII), etc.).
Pro tip: You can make use of Wrk Actions such as 'Replace string in text' or 'Replace text based on regex pattern' before sending the data to the Launch Console to mask the information.
Consuming Wrkflow Outcome
Keep the outcome for last
Keep the outcome for last
For Wrkflows that provide an end outcome such as a report in form of a file, or a result that is in a text format - ensure that the outcome arrives as the last update to the Launch Console. This will ensure that the user can easily access the outcome without having to scroll through other updates before getting to the outcome.
Single outcome
Providing an outcome at the end of a linear Wrkflow is as simple as using the Send to Launch Console Wrk Action as the last step in the Wrkflow:
Multiple outcomes
For non linear Wrkflows such as those that branch out or divides, consider using multiple ending each with its own update to the Launch Console:
Joining outcomes
Non linear Wrkflows can also join in branches to combine the outcomes into one. In the case of divides, the use of the Wrk Action Export Wrkflow data to file can combine all the results of previous Wrk Actions into one. This can be used to provide one singular update to the Launch Console:
Ending with an outcome is not relevant for Wrkflows that are transactional such as moving data from one place to another.
Debugging Wrkflow and monitoring errors
Errors are automatically sent to the Launch Console. As the designer of a Wrkflow, you do not need to use the 'Send to Launch Console' Wrk Action to bring execution errors to the Launch Console. However, there are situations that may not be considered as execution errors but are considered a failure from achieve the goal of the Wrkflow.
In the example above, an unsuccessful outcome to the API Wrk Action is not an execution error as it is a possible expected outcome from the Wrk Action. In those cases, sending the update to the Launch Console is useful.
Tip: You can label the update to differentiate between the updates by using the Notification Type select in the 'Send to Launch Console' Wrk Action.
