> For the complete documentation index, see [llms.txt](https://knowledgebase.autorabit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.autorabit.com/release-notes/release-notes/codescan-release-notes/on-premise-releases/eagle-edition/release-notes-26.1.1-eagle-8.0.md). # Release Notes 26.1.1 Eagle 8.0 **Release Date: 17 July 2026** ### Summary CodeScan Self-hosted 26.1.1 is comprised of the following 6 components: * 0 New Features * 0 Application Enhancements * 0 New Rules * 3 Rule Enhancements * 0 Rule Deprecations * 3 Fixes Component details are listed in their corresponding sections within this document. ### Rule Enhancements **1. Improved Rule Stability and Error Handling** Improved the stability and resilience of Apex rules execution by addressing multiple edge cases that could result in internal exceptions being exposed in analysis logs. Previously, certain rule evaluation scenarios could generate internal exceptions during analysis, resulting in Java stack traces being written to logs. Although analysis is often completed successfully, these errors could lead to incomplete rule evaluation and reduced confidence in results. Edge cases addressed: * SOQL Injection Rule Stability Improved handling of Apex data-flow analysis scenarios that could previously result in internal type-casting exceptions during rule evaluation. * LocaleInOldApi Rule Stability Improved handling of chained method invocations such as DateTime.now().format()to prevent internal rule execution errors while analyzing valid Apex code. * Defensive Null Handling Across Rule Execution Enhanced null-safety handling for multiple Apex rules, including: * Unescaped Output * SOQL Injection * Avoid SOQL in Loops Additional validation and defensive checks were introduced to ensure rule execution can safely handle unresolved AST and semantic-analysis paths without exposing internal exceptions. **Outcome** 1. Improves overall rule engine stability. 2. Prevents internal implementation details from appearing in analysis logs. 3. Reduces the risk of incomplete rule evaluation. 4. Provides more reliable and professional analysis output. 5. Improves confidence in analysis results for Apex projects. **2. Enhanced Documentation for Sensitive PII Field Detection Rule** Updated the documentation and guidance for the Identify Potential Sensitive PII Fields rule (*sf:SecurePIIFields*) to provide clearer information about the types of data covered by the rule and how organizations can extend detection coverage. **Documentation Improvements** The updated rule description now clarifies that certain standard Salesforce objects may contain sensitive personal information, including: * Contact * Lead * User * Account * Person Account * Opportunity Examples of potentially sensitive data include: * Names * Email addresses * Phone numbers * Physical addresses * Birth dates * Other personal identifiers The documentation also highlights the importance of protecting this information in accordance with privacy and security regulations such as: * GDPR * CCPA * HIPAA **Configuration Guidance** Organizations can define additional sensitive field names through rule parameters, including: * SSN * Social\_Security\_Number * Credit\_Card * Passport and other organization-specific fields that may contain regulated personal information. **Outcome** * Improves understanding of the rules' purpose and scope. * Provides clearer guidance for identifying and protecting sensitive data. * Helps organizations extend detection coverage to custom fields. * Supports privacy, security, and compliance initiatives through improved rule documentation. 3\. Enhanced Avoid Calling SOQL and DML Inside Loops Rule Enhanced the *sf:AvoidSoqlInLoops* rule to optionally detect Salesforce platform methods that consume SOQL queries internally when executed within loops. New Parameter | Parameter | Default | Description | | ----------------- | ------- | -------------------------------------------------------------------- | | checkInternalSoql | false | Checks for methods with internal SOQL consumption used within loops. | **Behavior** When enabled, the rule identifies supported platform methods that may consume hidden SOQL queries inside loops, for example: * Messaging APIs * UserInfo APIs * FeatureManagement APIs * Approval APIs * Flow invocation APIs * ConnectApi operations * Visualforce content APIs **Outcome** * Improves detection of governor limit risks. * Identifies hidden SOQL consumption. * Helps developers avoid query-limit violations. * Preserves existing behavior unless explicitly enabled. ### Fixes 1. **Improved SOQL in Loops Rule Accuracy** Resolved an issue where the Avoid SOQL in Loops rule (*sf:AvoidSoqlInLoops*) could incorrectly report violations for certain method invocation patterns, resulting in false positives. Previously, the rule could identify SOQL or DML operations as being executed within a loop based solely on nested method call analysis, even when the queried method was not actually invoked from a looping execution path. In some scenarios, method calls originating from Apex test classes could also be included in the analysis, contributing to incorrect findings. **Behavior** The rule has been enhanced to improve analysis accuracy by validating the actual execution path before reporting nested-call violations. Improvements include: * Reduced false positives for SOQL and DML operations that are not executed within loop constructs. * Improved evaluation of nested method invocation chains. * Exclusion of Apex test class method calls from nested execution path analysis. * Improved validation to ensure nested-call violations are reported only when a genuine loop execution path exists. **Improved Diagnostics** The rule now provides more accurate reporting by distinguishing between nested method calls and actual SOQL/DML execution within loops, reducing misleading violations for valid code. **Outcome** * Reduces false positives reported by the Avoid SOQL in Loops rule. * Improves accuracy of data flow and nested-call analysis. * Prevents Apex test classes from influencing production rule evaluation. * Provides developers with more reliable and actionable rule findings. * Improves confidence in SOQL and DML loop detection for complex Apex applications. 2. **Updated Guidance for Custom Field Requirement Configuration Rule** Updated the documentation and messaging for the Custom Field Security in Standard Object rule (*sfmeta:CustomFieldSecurityInStandardObject*) to provide clearer guidance on the recommended approach for configuring required custom fields on Salesforce standard and shared objects. Previously, the rule messaging did not clearly explain why marking custom fields as required at the schema level could have unintended consequences across different data entry mechanisms. The following rule metadata has been updated: * Title: Use the Page Layout to mark the custom field as required. * Message: Use the Page Layout to mark the custom field as required. * Description: Expanded to clarify that custom fields on standard and shared objects should be marked as required through page layouts rather than at the schema (system) level. The updated guidance explains that using page layouts limits the requirement to users interacting through the Salesforce UI, while avoiding unintended impacts on other data entry points such as: * APIs * Data Loader * Apex * Integrations Outcome * Provides clearer remediation guidance for Salesforce administrators. * Encourages Salesforce best practices for configuring required custom fields. * Helps prevent unintended validation issues across integrations and automated processes. * Improves the usability and clarity of rule findings. 3. **Improved Unused Formal Parameter Detection for Dynamic SOQL Queries** Enhanced the Unused Formal Parameter rule (*sf:UnusedFormalParameter*) to improve detection of method parameters used as bind variables in dynamically constructed SOQL queries. Previously, the rule could incorrectly report unused parameter violations when parameters were referenced as bind variables within dynamic query strings, such as queries built using the fflib QueryFactory pattern. Although these parameters were resolved and used by Salesforce at runtime, they were not recognized by the rule, resulting in false-positive findings. **Behavior** The rule now recognizes method parameters used as SOQL bind variables within dynamic query execution patterns, including: * Database.query() * fflib\_QueryFactory * Dynamically constructed SOQL query strings Support has also been expanded to recognize bind variables used with common SOQL operators, including: * \= * != * \> * < * \>= * <= * IN Existing detection for direct IN :variable usage remains unchanged. The rule continues to report violations for method parameters that are genuinely unused. **Outcome** * Reduces false positives for applications using dynamic SOQL construction patterns. * Improves compatibility with the Salesforce Enterprise Patterns (fflib) framework. * Provides more accurate detection of genuinely unused method parameters. * Increases confidence in rule results for projects using dynamic query generation. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://knowledgebase.autorabit.com/release-notes/release-notes/codescan-release-notes/on-premise-releases/eagle-edition/release-notes-26.1.1-eagle-8.0.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.