What Are False Positives?

False positives occur when Clayton flags an issue that doesn’t actually require fixing. These arise because static analysis tools like Clayton rely on generalized patterns and predefined rules to identify potential problems. In some cases, Clayton might lack the full context of the code’s purpose or implementation, leading to incorrect assumptions about an issue's severity or necessity for remediation.
​

For instance, a hardcoded value flagged by Clayton might be intentional for a specific use case, such as a sandbox environment. Similarly, test cases designed to simulate rare or unconventional scenarios may violate typical conventions but still serve their intended purpose. False positives can also occur when custom practices, like unique naming conventions, don’t align with Clayton’s default rules. Understanding why false positives happen allows teams to navigate these occurrences effectively and maintain trust in the platforms overall capabilities..
​

Clayton is continuously working to improve its algorithms and reduce false positives.
If you come across a genuine false positive, you can dismiss it by selecting the False Positive option, as shown above. When you report a false positive through the platform, it’s sent to the developers for review. Your feedback helps inform updates to the rule engine and makes Clayton smarter for everyone. When doing this, it's really helpful to include as much context as possible in the comment box, this gives the team valuable insight for reviewing the issue and refining the detection logic.
​

You also have the option to dismiss an issue by selecting Used for test as the reason. We understand that during early development or exploratory testing, some patterns may trigger warnings that aren't necessarily problems.
​

Alternatively, you can mark an issue as Won’t fix. In large repositories, it’s not always feasible to resolve every issue, and this option helps developers focus on what matters most by setting clear priorities.
​
​

Managing false positives in Clayton is a straightforward process. When you identify a flagged issue that you believe is a false positive, navigate to the Scan Results section.
​
Click on the issue to review its details, including the file, line number, and specific rule it violated. If you determine the issue does not require action, use the Dismiss button to exclude it from future scans.
​

When dismissing an issue, Clayton prompts you to provide a reason and add a comment explaining your decision. This information is logged for auditing purposes, ensuring transparency and accountability.
​

Clayton maintains a full audit trail of all dismissed issues, allowing you to track exactly who dismissed each item and when. To review dismissed issues, navigate to the Dismissed tab located beneath the search bar. This provides a comprehensive list of all items that have been manually dismissed.
​

Selecting an individual issue displays the original rule violation, the specific line of code involved, and context around why it was flagged. The Timeline view offers a chronological history, including when the issue was first introduced, detected in a scan, and critically, who dismissed it, the exact time of that action and the reason given.

There may be cases where a rule repeatedly flags issues that you believe are false positives, creating unnecessary noise or distractions in your workflow. In these situations, it’s worth considering whether that rule should remain active in your policy.
​

When you first connect a repository or Salesforce org to Clayton, many users go with the default set of rules and policies. We’ve designed this default selection to reflect industry best practices, but we know they might not suit every team’s specific setup.
​

If you decide a particular rule isn’t relevant for your project, users with the appropriate permissions can disable it by following these steps:
​
In the Admin tool, go to the Policies tab, then click Edit under the Actions column next to the policy you want to modify.
​

Next, choose the policy that includes the rule you want to manage. From there, you can toggle the rule on or off, or adjust its severity level to better fit your team's needs.
​
Keep in mind, disabling a rule will apply globally, meaning it won’t be enforced in either Salesforce org scans or repository checks
​

While some false positives are inevitable, teams can take proactive steps to minimize their occurrence. First, customize Clayton’s policies and rules to better align with your organization’s coding standards. For example, if your team follows a unique naming convention for test classes, you can modify or disable rules that conflict with your practices.
​

Second, ensure your team has a clear understanding of Clayton’s rules and policies. Providing training or creating internal documentation helps developers write code that aligns with Clayton’s expectations, reducing unnecessary flags. Finally, use the Legacy Code Toggle to focus on new issues, as legacy code often contains exceptions that are better addressed incrementally.