There can be hundreds of reasons why an issue is happening. This makes it very hard to determine the root cause of an issue in order to create a solution.

The first step and perhaps the most important step in the whole debugging process, is making sure that you are able to reproduce the issue. When you are able to reproduce the issue you can make use of several debugging tools that are available within the Betty Blocks platform or within your browser.

If you are unable to reproduce the issue you can spend hours, days, or even weeks on finding the issue first. And you will never be able to determine yourself if you have fixed the issue once you have made some changes.

To reproduce the issue you can ask the following questions to the reporter. That will allow you to reproduce the issue and solve the issue a lot faster.

Below is a small example of how an issue should be reported.

Title

Unable to create new projects within the dashboard @exmapleapplication

Description

When I try to create a new project on the dashboard page the new project is not showing up

Current behavior

When I try to create a new project on the dashboard page I am able to fill in the form and press the save button. The project does not show up on the dashboard page in the project's overview.

Expected behavior

After I have filled in the project fields and pressed the save button. The project must show up directly within the project overview on the dashboard page.

An issue can happen for multiple reasons. However, we are able to determine if an issue is happening due to a technical error or a functional error. Depending on the type this will determine the steps you can take to investigate and resolve the issue. And also determine if you are able to solve the issue yourself based on your skill level. But how can you determine if an issue is technical or functional?

First, you will need to understand the difference between these two types. A functional error can be seen as an error where the user expects something to happen. But the system does something else.

With functional errors there is a lot of room for interpretation, depending on the person who looks at it. A programmer (Pro-coder) will say the action works without any issues. But an end-user will say it does not work because it does not meet the user's expectations.

For example: When a user creates a new project, the user expects that the status of a project will be set to ‘new’ by default. However, the logic that actually creates the project is configured that the default status will be set to ‘In progress.

In this case from the user perspective, it does not work. But from a technical perspective, it works perfectly.

And where a technical error will typically always generate some kind of error message that will be visible for the end-user and/or the pro-coder. Making a lot less room for interpretation.

For example when something goes wrong after a form is being submitted. The following error will show up.

Now that we know the difference between a technical or functional error. We can determine the type of issue that is reported.

Again there are different methods you can use from simple to very complex. I prefer a very simple but effective approach.

You can classify the issue as a functional error when a user is able to finish a process within the application, and the end result does not meet the user's expectations.

If this is not the case you can classify the issue as a technical error.

As a small help, the following diagram could be helpful.

Now if we look back at the given example When a user creates a new project, the user expects that the status of a project will be set to ‘new’ by default. However, the user notices that the status of the project is set to ‘In Progress'.

Because the user is able to complete the process of creating a new project without any errors you can say that this is a functional error.

When the user was unable to complete the process and got stuck or got an error that was not designed. You can say that this is a technical error.

Please note that this logic is not 100% accurate and you always will have exceptions.

Depending on the skill level of the person, you could determine what type of issue should be looked at by what type of developer.

Technical errors usually require more knowledge of the Betty Blocks platform and IT knowledge in general. Where functional errors could be more easily solved once you know where to look. And does not require a high IT knowledge skill level.

Functional errors can be solved by every type of developer:

Because a function error most of the time is happening due to a wrong configuration somewhere in the business logic of an application. These types of issues are likely to be solved very fast by someone who has a good understanding of the business logic within the application. Typically that is a citizen developer or a no-coder

Technical errors typically require a better understanding of the underlying IT technique to investigate and solve the issue. So these types of errors can be solved best by a:

Now that you are able to reproduce the issue and identify the issue type you can start debugging. Because each issue is unique and requires a different type of approach it is very hard to create a step-based plan that will always help you to find and solve the issue.

To give you more insight into what the possible options are we will provide you with several example issues and what tools and steps were used to identify and solve the issue in the end.

Each example will contain details about the issue and then the steps that are taken to investigate and solve the issue.

A common error is an error that an action is started but the end result does not match up with the user's expectations. For example:

Title

Unable to create new tickets within @debug-exmaple application

Description

When I try to create a new ticket, the ticket is not showing up on the ticket overview page

Current behavior

When I try to create a new ticket I am able to fill in the form and press the save button. The ticket does not show up on the ticket-overview page.

Expected behavior

After I have filled in the ticket fields and pressed the save button. The ticket must show up within the table on the ticket-overview page

Steps to reproduce

If we follow the diagram to determine if this is a functional or technical error we can say that this is a functional error. In that case, your first check should be in the configuration of the application itself. In this case, the action that will create the new ticket.

First, we can go to the page itself, find the form component, and view the linked action.

When you take a closer look at the action we can see that the action contains a single create event. And the create event itself also looks good, meaning the configuration of the create event does not contain any unknown variables, UUID’s or other strange settings.

So it is safe to say the action itself is not the issue

The next step you can take is to see if the ticket data is being created in the back office. If the ticket data does show up in the back office you can eliminate the option that the action is not being started at all.

By doing so we can also test the form itself. In this example, we see that the form itself does work correctly. Because a confirmation message is displayed after submitting the form.

When checking the ticket overview we can see that the ticket is not listed on the table.

So now let’s take a look at the back office data. When we open the back office and look at the ticket data here. We can see that the ticket has been created and added to the database of the application.

Since the ticket is created. We can eliminate the option of the action not working.

As you might have noticed, the status of the newly created ticket is empty. And all other tickets do have a status. So perhaps the ticket overview page is set up so that the tickets without any status are not displayed.

The next step is to take a look at the data table and the way it has been configured. Here we can see that the table indeed has a filter option configured.

When we look at the filter settings. We can see that the tickets without a status are not visible within the table.

You can now solve the issue in multiple ways. Update the action so that the ticket always gets a default status, or you can remove the filter of the data table. In this example, we have removed the filter and that will solve the issue. As you can see below the ticket is not listed within the table.

Another example of an issue is that the form that is being filled in, is not saved correctly into the database of the application. For example:

Title

Description of a ticket is not saved @debug-exmaple application

Description

When I create a new ticket, the filled in description is not saved/displayed in the ticket overview

Current behavior

When I create a new ticket, the flled-in description is not saved/displayed in the ticket overview. The ticket title however is visible

Expected behavior

When I create a new ticket, both the description and title field are visible on the overview page

Steps to reproduce

Debug process

When we look at the diagram we can determine that this is a functional error. Because the user can complete the whole process (create a ticket) but the end result does not meet the expectations.

The first step is to reproduce the issue yourself. When following the steps provided we can see the same results. The form is submitted successfully because we can see the confirmation message.

When we look at the overview page we can see that the ticket is created, But the description is empty.

The first step would be to take a look at the linked action. To see if the action is configured correctly.

When we open the action we can see that the action contains a single creation event. And the create event contains 2 assigned properties. The title and description.

So it looks like the action is set up correctly.

The next step is to enable debug mode on the action so that we can see what is happing when the action is started.

To enable the debugging, go to the action settings and check the debug option.

When we reproduce the issue again we can now check the logs for more information.

Within the logs, we can see that there is no error. So that is a good sign. We can now also see what variables are used and what data these variables contain within the action.

Because we are missing the description. The first thing we can check is to see if the data from the form submitted does indeed contain the value of the description field that was entered on the form.

We can de data value of the from_data variable when you click on the variable within the logs. And we should expect to see values. The title and description.

As we can see, we are missing the description value of the form. So that is why the description is not saved when a new ticket is created.

Our next step is to enable debug mode on the linked endpoint so that we can see that data is being sent from the form. When you submit a form on a frontend page. The data that is filled in within the form will be sent to a POST endpoint. This endpoint will then trigger the action linked to the form component.

In our logs, we can see the connected endpoint that is linked to the action.

When you click on the link of the endpoint you can enable debug mode on this level as well.

Now that we have enabled debug logging on the endpoint level as well, we can see more information within the logs when we reproduce the issue again.

When we take a look at the logs and press the request button. We can see the exact details that are begging send from the frontend page.

When we take a look at the incoming request. We can see that the from_data does indeed contain the value that is filled in within the form.

But the field within the form_data is called “desc” And when we look at the action event. The event expects “from_data.description”.

Because of this miss alignment, the description is not saved. And the good news is that we have found the root cause of the issue so we can now solve it!

The reason for the misalignment, in this case, is that a setting on the input field component is not correct.

When we select the input component on the page and look at the advanced options, there is an option called “Name attribute”. This setting will allow you to change the name of the from_data variable that is used.

When we change the setting to “description” And the test the whole flow again. We can see the change within our logs. The from_data does now contain the correct naming “description” that is used in the action.

And the solves the issue! As we can see, the descrition is now saved again.

The Betty Blocks platform uses the GraphQl technique to request and display all the data within the page builder. So if something goes wrong in loading the data on a page, a common error is a graphQL error.

This typically happens when the permissions for a user (or public) page are not set correctly to display the data on a page builder page. For example:

Title

Unable to see ticket information @debug-exmaple

Description

When I try to view the ticket information I am getting a strange error

Current behavior

When I try to view the ticket information I am getting a strange error. I am able to visit the page but the table is not displaying any ticket information

Expected behavior

When I visit the ticket overview page I want to see all the tickets and the information

Steps to reproduce

The error itself on the screen says GraphQL error: Unauthorized for model(s)... Based on the diagram flow we can determine that this is a technical error.

As mentioned before, this type of error should be looked at by someone who has more knowledge about the platform and IT in general. A no-coder or a Pro-coder.

The error itself could already give you an idea of how to solve the problem. But if you want to see the complete error message, or need more information. You can use the developer tools of your browser to get more information.

You can open the developer tools by right-clicking and inspecting your page or use Option + ⌘ + J (on macOS), or Shift + CTRL + J (on Windows/Linux).

And now you can select the network tab.

The network tab will help you to see what requests are being made when the page is loaded and find more details of the requests. In order to see the requests you must have the network tab open, and then reload the page so that all requests will be visible

Te reduces the amount of information that will be shown. Use the Fetch/XHR filter. The result will look something like the below.

As you can see there are several requests being made. The trick is to find out the right requests. Alle requests that will be made to the DataAPI of a Betty Blocks application will have a UUID as the name. Once you click on a request you are able to get more information and are able to see for example the complete error. See the example below.

For this example bug, you should now have enough information to solve the problem. In this case, you must set the permissions to the public for the ticket model.