Introduction
With the foundation laid, we are now ready to explore logging in Dataverse using Power Automate Flows in practice.
Here is a brief overview of the journey so far:
- In Part 1, I just introduced the concept.
- In Part 2, the establishment within Dataverse was covered.
- In Part 3, the child flow called Add Log was introduced, which is responsible for creating the log.
Now, let’s see how to call this flow and examine the value it provides.
Main Power Automate Flow and its logic
To enhance the functionality of your system, choose one of your main flows to add more value. In my example, I have a flow responsible for creating a job offer after receiving an email. This flow utilizes AI Builder to extract the Description and Budget range from the attached PDF.
Here is the high-level structure of the Flow:
As you can see, the flow includes a trigger and two scopes. The main scope, “Try,” is responsible for executing the primary actions, while the “Catch” scope handles any exceptions that may occur in the “Try” section.
Using this structure is a best practice for implementing Cloud flows. The following picture illustrates the last 4 actions out of the 12 in the “Try” scope, where the Add Log child flow is called.
The following picture shows the result of a successful execution of the flow. If above actions 1 and 2 execute correctly, the Description and Budget Range are extracted. Action 3 will create a Note to inform the user that, since the information was set by AI, they need to review it before publishing to the portal.
However, I intentionally designed my flow logic to depend on having a PDF as an attachment. This means I could disrupt the flow by sending an email with a Word file as an attachment. We will see the impact of this scenario later.
Utilizing the Log Flow
Within my main flow, I have utilized the log twice. One instance logs a successful operation. To achieve this, I use the “Run a Flow” action and select the “Add Log” child flow. The descriptions provided for our child flow parameters (explained in previous blog post) are now instrumental in determining what values to send, as depicted in the picture.
The Subject and Description fields are populated with context-specific text. You can include values from previous actions in the Description or even in the Subject if needed, as this can be helpful during troubleshooting. By sending the workflow() function as a parameter, we ensure that our log has access to the flow run, allowing us to see what happened within our flow.
The remaining parameters are straightforward: I set the Regarding Logical name, its plural name, and the ID of my job offer record as Regarding Id. This ensures the log is associated with the appropriate record’s timeline. The Log Type 763000000 corresponds to Information, and Priority 0 corresponds to Low. While Priority can be used for retention policies, that is beyond the scope of this blog post.
Logging success is crucial for understanding which logics have been executed on our record. This is particularly useful when different logics from various flows are applied to the same record.
To log an error, we first need to set up our Catch scope. As shown in the following picture, we can configure it to execute only when the Try scope is not successful. This means that if any action within the Try scope fails, the Catch scope will be triggered. Once this configuration is in place, we can add our Log Error action inside the Catch scope.
Logging an error is very similar to logging a success, but with a few different values. For an error log, I set the Log Type to 763000002, which corresponds to Error, and use a different Priority, such as 2, which corresponds to High.
Ensuring a Happy Support Team
In this section, we’ll demonstrate how our robust solution can keep the support team happy, even when things don’t go as planned.
Imagine the customer sent an email with a Word file as an attachment. As mentioned earlier, this will disrupt our flow logic. Consequently, Miriam, the user, will notice the following: no Description and Budget Range are extracted, and there is no Note in the timeline.
Now, she creates a ticket or calls the support team and provides them with the job offer URL.
The support agent then opens the job offer record and switches to the Admin form. They can see the error logged in the timeline, with the information we previously configured in our flow.
For more information the agent open the log activity and then click on “More Details”.
As you might recall from part 2 in this series, a new tab is opened with the flow run. Here is what the agent see (if they have access to the flow):
With a little zoom in, here are the last steps. Now, they can easily identify that the flow needs improvement to handle Word files as well, without much effort.
But what about our success log? Naturally, Miriam is satisfied with the successful execution and won’t report it. However, if we open the success log and switch to the Admin form, we will see the following details.
And by opening the activity:
And by clicking on the “More Details” button, we can see that the Catch part was not executed because the Try part was successful.
Conclusion
To reiterate the conclusion from the first blog post:
As you can see, with Intentional Logging, the support agent is guided directly to the point of failure, enabling a much faster resolution of issues.
Advantages of Intentional Logging:
- Standardized Logging: Provides a consistent logging approach for everyone. When a problem occurs, everyone knows where to look for the root cause.
- Direct Guidance: Guides the agent from the point of issue to the point of failure seamlessly.
- Ease of Use: Often, the point of issue is a record. Without knowledge of the system’s architecture, it would be challenging to pinpoint the failure. In the example discussed in this post, the agent didn’t need to know that a Cloud flow was responsible for creating the job offer. The log itself provided the necessary guidance.
- No Special Knowledge Required: Users do not need specialized knowledge to utilize it.
- Customization Independence: Although my focus in this blog series was on Power Automate Flows, Intentional Logging works regardless of the type of customization. Whether you are using JavaScript, plugins, or any other components, you can implement Intentional Logging effectively.