Overview
The rule is designed to scan configuration components where hardcoded IDs most commonly appear and can cause deployment or runtime issues. In its current implementation, the rule checks for hardcoded IDs in the following areas:
Flows & Process Builders: Code Reviews identifies hardcoded IDs within
Get Records,Update Recordscriteria, and decision elements.Validation Rules: The tool detects when a validation rule’s formula contains a hardcoded record ID.
Custom Buttons & Links: Code Reviews also scans these components (as part of its analysis of custom objects and fields) to identify embedded record IDs.
These are the only configuration elements currently covered by this rule. Other components such as Apex Classes, Workflow Rules, and Email Templates are outside the scope of this particular check.
Why This Matters Using hardcoded IDs in configuration can lead to:
Deployment Failures: Customizations containing hardcoded IDs will break when moved to a new environment (e.g., from a sandbox to production) because the referenced record IDs won't exist or will refer to different records.
Runtime Errors: Even if deployed, the logic might fail silently or produce incorrect results if the hardcoded ID points to a non-existent record or an unintended record in the target environment.
Maintenance Headaches: Identifying and replacing hardcoded IDs across numerous configurations is a time consuming and error prone manual process during deployments or troubleshooting.
Reduced Scalability and Portability: Customizations become tightly coupled to specific environments, hindering multi org strategies, package development, and continuous integration practices.
Increased Technical Debt: This anti-pattern introduces significant technical debt, making the application more brittle and costly to maintain over time.
Recommended approach
Instead of relying on hardcoded IDs, Salesforce recommends several alternatives that maintain portability and scalability. One effective approach is to use Developer Names, which remain consistent across environments for many metadata types, such as record types, profiles, and permission sets. For example, when referencing a record type in a formula or process, using its Developer Name rather than its ID ensures that your configuration will continue to function correctly across different environments.
Another recommended practice is to using Custom Metadata Types or Custom Settings to store configuration data, such as key record references. This approach allows these values to be easily maintained, versioned, and deployed between environments without introducing environment specific dependencies.
For integrations or configuration dependencies, using External IDs provides a reliable method for referencing records without relying on environment specific record IDs. External IDs act as stable, unique identifiers that remain consistent across deployments.
Finally, Salesforce encourages dynamic resolution within Flows and Processes. Rather than embedding record IDs directly, you can use “Get Records” elements to query records dynamically based on consistent field values such as the Developer Name or API Name. This method ensures your automation logic remains portable, scalable, and resilient to changes between environments.
What Triggers This Rule
Code Reviews flags instances where Salesforce record IDs (typically 15- or 18-character alphanumeric strings) are found directly embedded within:
Formula fields
Validation rules
Workflow rules or Process Builder criteria
Flows (e.g., in "Get Records" filters, "Update Records" criteria, or decision elements)
Custom settings or custom metadata type records (when storing record IDs)
Summary
Hardcoded record IDs in Salesforce configurations lead to Errors because record IDs change between environments. Any logic that uses hardcoded IDs will fail when deployed to a different Salesforce environment. Code Reviews detects these instances to prevent deployment failures and ensure the portability and reliability of your application. Employing External IDs, Custom Metadata Types, or querying for IDs at runtime are crucial best practices for building scalable and maintainable Salesforce solutions.