> For the complete documentation index, see [llms.txt](https://community-test.logicnets.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://community-test.logicnets.com/release-9/platform-documentation/process-node-parts/get-tab-progress-beta.md).
# Get Tab Progress (BETA)
## Description
In applications based on the Assessment Framework you can use validations and provide on-screen messages to communicate errors, all to ensure users answer questions correctly. Examples of validation include:
* verifying that the user answered a mandatory question
* verifying if an answer does not match the specified validation criteria; for example, if a numeric answer must be between zero and 100
The *get\_tab\_progress* part counts errors like these from all logicnets that the system processes in the *forms* folder during runtime. Remember, the logicnets in the *forms* folder are those the system uses to generate tabs in the Assessment Framework user interface.
NOTE: This part is currently in Beta release for v8.1. It is located in process nodes in the *App Dev* dropdown menu.
## Use
The most common uses for this part are as follows:
1. You can use the total error count, for example, to determine the number of errors and display the report only once there are no remaining errors in the forms section of an assessment framework application.
2. You can use the current tab total error count to display a message to the user that the current section is complete and all mandatory questions have been answered.
### Common Usage
For most applications of this part you will use the *total error count* and/or the *current tab total error count* parameters.
* You do not need to specify the logicnets, because, by default, the part evaluates validation errors in all logicnets in the *forms* folder and any logicnets they call.
* You do not need to specify names for the additional parameters, which look at particular subsets of error types. For more information on those, see below.
### Error Types
The system actually counts two types of error:
* Visible validation errors: These are validations that display a user-defined error message on screen when they fail. When a tab in the Assessment Framework contains **visible** validation errors, the tab status shows a white cross in a red circle. As an example, look at the "Other" tab in the image above.
* Hidden validation errors: These are validations that do not display a user-defined error message on screen when they fail. When a tab in the Assessment Framework contains **hidden** validation errors, the tab status shows an exclamation point in an orange circle. As an example, look at the "Checklists" tab in the image above.
If there are both visible and hidden validation errors, the visible errors dictate the tab status and the system displays the red circle.
Ideally, you want to create your application so it shows the user a validation error message that gives a hint as to why an answer failed; for example, that they needed to enter a number between 0 and 100. However, you can make a field mandatory but not set an error message for the user, because the LogicNets Assessment Framework has a default action to bold a question caption and postfix a red asterisk next to a field until the question has been answered. This communicates mandatory questions to the user without displaying multiple validation messages. In this case, the system counts these validation errors as hidden.
Note that the default styling for mandatory questions in Assessment Framework applications can be overwritten by your custom CSS.
### Node Placement
Where you place the *get\_tab\_progress* part is important, because the system does not include in the error counts any errors after traversing this node. So, you would normally place this node in a report logicnet, because that runs after the system cycles through all form tabs. In some cases, you may not want to have the system count errors from all logicnets. You use the *Exclude logicnets* option to manage which logicnets get included.
For more information on setting validation rules on questions, see [Setting Conditions - Data Validation](/release-9/platform-documentation/other-help-articles/setting-conditions-data-validation.md).
**Used With:** This part is only for use with Assessment Framework-based projects.
## Editor Fields
| Field Name | Description/Use | Type/
Options
| Optional/
Mandatory
|
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | ----------------------------- |
| Assessment Logicnets | By default, this field is empty but the system assesses all logicnets in the forms folder.
To include specific logicnets in your error count, you can create a complex collection with net = "\[name of logicnet to error check]" as entries. You can do this in a variety of ways, but below is one simple approach, using a set data object to create the progress\_net\_list container that presents the Introduction and Calculations logicnets.
| Container | Optional |
| Exclude logicnets | This is the list of logicnets the system should not include when counting errors. The list should be provided in the same way as for Assessment LogicNets above (collection of net = "XXX" in a container).
Alternatively, you can format this list as a quoted, comma-separated string; for example:
"main", "initialize", "report", "on\_load"
| Container \| Text | Optional |
| **All Error Counts** | | | |
| Total errors | This is the data object that will contain the sum of all validation errors. | Optional | |
| Visible validation errors | This is the data object that will contain the sum of all counted errors, except the validation errors. | Data Object | Optional |
| Hidden validation errors | This is the data object that will contain the sum of all hidden validation errors. It will not include visible validation errors. | Data Object | Optional |
| **Current Tab Error Counts** | | | |
| Total errors | This is the target data object that will contain the sum of all errors for the current active logicnet/Assessment Framework tab. It includes both visible and hidden validation errors. | Data Object | Optional |
| Visible validation errors | This is the target data object that will contain the sum of all visible validation errors for the current active logicnet/Assessment Framework tab. | Data Object | Optional |
| Hidden validation errors | This is the target data object that will contain the sum of all hidden validation errors for the current active logicnet/Assessment Framework tab. | Data Object | Optional |
## Example Project
To see this part in use in an example project, download the *ASF How-To Guide: Introduction to Validation (8.1+)* that is included [here](/release-9/example-gallery/how-to-guides/asf-how-to-guide-validation-example-project.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://community-test.logicnets.com/release-9/platform-documentation/process-node-parts/get-tab-progress-beta.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.