Project Health
- 12 Sep 2024
- 5 Minutes to read
- Print
- DarkLight
Project Health
- Updated on 12 Sep 2024
- 5 Minutes to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
Overview
Project Health is a feature within a Project that assesses the Project's overall condition and the individual health statuses of its elements. It allows users to gauge the efficiency and adherence to best practices within the Project.
Ensuring consistent performance and adherence to best practices can be challenging in Projects with complex structures and multiple interconnected elements. Identifying specific areas requiring attention and improvement becomes labor-intensive and time-consuming. Consequently, this lack of streamlined Project maintenance can lead to inefficiencies, errors, and delays, ultimately impacting Project timelines and overall productivity.
By leveraging Project Health, users can swiftly identify and address potential issues within the Project structure, enabling proactive maintenance and optimization efforts. The feature's detailed evaluation and scoring mechanism facilitates quick identification of potential issues. This streamlined approach to Project maintenance enhances overall Project efficiency and maximizes productivity, leading to improved Project outcomes.
Health Dashboard
The Health Dashboard has detailed evaluation and scoring mechanisms that are instrumental in maintaining and enhancing the overall health and efficiency of the Project, ensuring adherence to best practices and streamlined Project management.
The Health Dashboard offers a comprehensive view of the overall Project health and the individual element's health. It presents an overall health score tile representing the average of all individual element scores. Below this, separate tiles display average health scores for each category of designer elements. Each element is listed with its individual score, and users can expand each element to view the specific conditions that must be fulfilled to improve its score. Hover over any element to reveal the edit icon 
, select this to navigate to the element, and perform suggested fixes.
Recalculate Health Score
Health can be updated by running the Recalculate Project Health Action. When the Project Health dialog appears, select YES.
Scoring Conditions
There are specific scoring conditions to evaluate the various elements, such as Flows, Forms, Rules, Reports, and Data Structures. Each category has its requirements and conditions that must be met to ensure the optimal functionality and performance of the elements. These conditions range from the complexity of Flows and error handling to control counts and validation issues for Forms, Rules, Reports, and Data Structures.
Data Structures
| Condition | Requirement |
|---|---|
| Inefficient FileData Handling in Data Structures (v9.3+) | Data structures containing FileData can lead to performance issues if not handled properly. Ensure that file data is managed efficiently within the data structures. |
| Invalid Data Structure (v9.3+) | Data Structures with an invalid status that have run into errors compiling and need to be addresses to maintain functionality. |
| Excessive Data Structure Size (v9.3+) | Data structures that exceed 30 fields may cause performance issues. Consider breaking down large data structures into smaller, more manageable ones. |
| Avoid Recursive Data Structure Design (v9.3+) | Designing data structures with recursive types can lead to increased complexity and potential performance issues. It is recommended to use iterative approaches or alternative designs to improve maintainability and efficiency. |
| Data Type Database Storage (v9.3+) | Ensure that data types used in the Data Structure can be stored correctly in database. |
Flows
| Condition | Requirement |
|---|---|
| Flow Name | Always rename the Flow to make their purpose within the project clear. |
| Description | Always provide a clear description so other editors can understand why this design exists. A good score requires a character count of at least 100. |
| Flow Complexity | Flows with more than 30 steps may be hard to understand. Consider using subflows to break down complex processes into more manageable sections. Any Flow with less than 30 steps scores a 100. Between 30 and 60 scores 50, and over 60 steps earn a score of 0. |
| Error Handling | Flows should have error-handling steps and use Log Steps to record information about unexpected conditions. |
| Unit Tests | Every Flow should have at least two unit tests to earn a passing score. |
| Validation Issues | List of validation issues found within the Flows. |
| SQL Steps | Using the Raw SQL step exposes Flows to many risks and is difficult for non-developers to understand and maintain. Please consider using a Defined Query step, which creates a self-contained Flow step. |
| Delete Entities | Ensure the Delete Entities step is configured to have filter criteria to prevent the deletion of every entity within the database for the selected data type. |
| Step Connections are Logical | Steps in the Flow have more than one path connected to the same destination step. This may mean data is unavailable, and the Flow may encounter errors. |
| Unused Inputs | If any input data is declared, it should be used within the Flow. |
| Step Names in Flow | Steps should be renamed in the designer to clarify how it is being used. |
| Send Folder Change Event (v9.3+) | Send Folder Change Event steps changes the Folder for the entire platform, this may cause issues. We recommend using the Send Folder Change Event For User or Send Folder Change Event For User Session. |
| Direct Exception to End Step (v9.3+) | Flows should not catch exceptions directly to an end step as it bypasses proper error handling and logging. Consider adding appropriate error handling steps before ending the flow. |
| Ambiguous Next Step Paths (v9.3+) | Step should not have multiple outcome paths entering the same next step, as this may cause confusion and unexpected behavior. Ensure different paths are used for different outcomes. |
| Run Flow for List Step (v9.3+) | Having a Run Flow for List step inside another Run Flow for List step can lead to performance degradation. Consider alternative design patterns to improve efficiency. |
| Pause Step and Delay Next Step (v9.3+) | Flows should not contain steps that delay or pause the Flow in any manner, as this can lead to performance issues and unpredictable behavior. |
| Unit Test Failure (v9.3+) | Unit tests are essential for verifying individual components work as expected. Failure in unit tests indicates issues that need to be addressed before deployment to ensure reliability. |
Forms
| Condition | Requirement |
|---|---|
| Form Name | Always rename the Form to make their purpose within the project clear. |
| Description | Always provide a clear description so other editors can understand why this design exists. |
| Control Count | The more controls there are, the more complicated a Form becomes. Forms with over 10 controls cause a warning. Over 20 will greatly decrease the Health score. |
| Validation Issues | List of validation issues found within the Form. |
Rules
| Condition | Requirement |
|---|---|
| [Rule Type] Name | Always rename the Rule to make their purpose within the project clear. |
| Description | Always provide a clear description so other editors can understand why this design exists. |
| Validation Issues | List of validation issues found within the Rules. |
| Rule Inputs | -- |
| Unit Tests | Every Rule should have at least two unit tests. |
| Inefficient Rule Collection Filter (v9.3+) | Using old rule collection filter steps with a single line inside of a rule can be inefficient. Consider refactoring the rule to use more efficient methods or steps. |
Report
| Condition | Requirement |
|---|---|
| Report Name | Always rename the Report to make their purpose within the project clear. |
| Description | Always provide a clear description so other editors can understand why this design exists. |
| Report Paging | Ensure that Paging remains enabled. If Paging is disabled, the Report may load large data sets, impacting performance. |
| Report Row Count | Report Row Counts should remain at 500 or lower. If the Row Count exceeds 500, the Report will use significant memory and likely cause end-user problems. |
| Flow Inline Fields | Flow Inline Fields can cause performance problems with large data sets. Please consider an alternate method. |
| Row Coloring Rules | Ensure the Report does not have more than one Coloring Rule. More than one Coloring Rule is difficult to maintain and uses many system resources. |
| Flow Report Source | Report Data Sources that run Flows do not scale. Please consider an alternate approach to this Report. |
| Rule Based Filters | Rule Filters should not be used on Reports that many users access. Please consider an alternate way to filter this Report. |
Feature Changes
| Description | Version | Release Date | Developer Task |
|---|---|---|---|
| 12 more Health conditions added. | 9.3 | September 2024 | [DT-041880] |
Was this article helpful?
