After reading this article you’ll know the following:
Use and options of the log message step
Best practices when applying this step in your actions
It’s not a secret that when building your own application, every now and then it doesn’t go as you want it to go on the first try and sometimes you might run into several issues. That is why we need testing and debugging/troubleshooting tools - to identify the root cause of broken functionalities. When working with actions, one can employ the action step called ‘Log message’ that pinpoints where something breaks within your flow creating a lot of insight visible through logs.
Check out this video explaining the log step
Log message use
The best way to understand the use of a certain feature is to try it out in practice. Thus, we are going to build a simple action flow and take it as an example.
Let’s say there is a number of tasks with statuses ‘To do’, ‘In progress’, and ‘Done’, and we want users to be able to update those (setting to ‘Done’). For this reason, the ‘Condition’ step will be added, followed by the ‘Update’ in the true flow. Records will be updated in case they exist and have statuses ‘To do’ or ‘In progress’.
Now, we are going to add the log messages steps, because unless we do that, we won’t be able to know the result of one particular action step, and if everything goes according to plan as we are building our action flow.
1. The first log step will be added right after the ‘Start’. We have to do this to make sure that action actually starts (triggers) and the right task gets passed to the condition step.
Here’s what the log message options are used for:
Severity field displays the type of message you want to be displayed in the logs overview
Variables show the context of variables that are specified. You can use static or dynamic variables to see the context in the log message you receive in logs. Add as many of them as you need.
Note: It’s worth giving the log message the name of the particular action so that when you have multiple actions running, it's easy to identify which action a log message belongs to.
The result of all action steps is visible in Tools > Logs. Let’s check if what we set gets the right output in the logs.
You can see, there are three latest log items:
All actions have been compiled
Our action was triggered
Two items were logged: ‘Action Start: True’ and ‘Task Object: Do Laundry’
It’s working!
2. Next, we’ll add one more log message step after the update step in order to check if the status of our task gets changed (from ‘In progress’ or ‘To do’ to ‘Done’). To do this, we need to pick up the variable value taken from the updated task.
Again, in the log overview we get the updated task, and the status of ‘Do laundry’ is set to ‘Done’.
3. Finally, let’s add a log message to the ‘Else’ flow. This time as we would like to see some users trying, but failing to update a record, so we set a variable value to ‘task_object’: Task’ and choose the error message with a specific name to be shown.
If a user tries to update the record with an ID that doesn’t exist or the record’s status was already changed to ‘Done’, we will instantly receive a ‘Failed to update’ message popping up in logs.
So that’s how the log message step can be applied in such use cases, and after getting to know how and why it is used within your actions, you will be able to find errors and bugs and make sure your application runs according to your plan.
We also recommend looking into Testing and debugging article on how to run tests in your application and undertake debugging with the help of log message step functionality.