Overview
This rule flags any use of hardcoded Salesforce record IDs in Apex code, Flow configurations, or metadata settings. While it may seem convenient during development, hardcoding IDs makes your org brittle and creates major deployment and portability issues.
Code Reviews classifies this as an Error because hard coded IDs tightly coupled logic to specific environments, often causing failures during deployments, migrations, or tests.
Why This Matters
Salesforce record IDs are unique to each environment (e.g. sandbox, production, scratch org), so hard coding them leads to:
Deployment failures: IDs may not exist in the target org, breaking Flows, tests, or automations.
Environment coupling: Code becomes locked to a specific org, reducing portability and reusability.
Testing challenges: Hardcoded references make tests fail unless exact data exists.
Maintenance headaches: If referenced records are deleted or renamed, logic silently breaks.
These issues make your automation brittle and harder to scale.
What Triggers This Rule
Code Reviews flags any string literals or Flow references that resemble Salesforce IDs, especially 15- or 18-character alphanumeric strings used for:
Record references in Apex (
'0015g00000XYZabc')Default values or filters in Flow Builder
Configuration in permission sets or validation rules
Example of a Violation (Apex)
// Hardcoded ID consider replacing with a dynamic or configurable value Account acc = [SELECT Name FROM Account WHERE Id = '0015g00000XYZabc'];
Recommended Approach
Hardcoding values in your Salesforce code can be inflexible and difficult to maintain. A better approach is to use one of the many available methods for storing values outside of your code. This makes it easier to update configuration details without needing to modify and redeploy your code.
There are several common alternatives to hardcoding, each with its own specific use case:
Custom Metadata Types: Store reusable, application-specific data and configuration settings. They are deployable and packageable, making them ideal for managing a hierarchy of settings.
Custom Settings: Similar to custom metadata, they let you store and retrieve application-specific data. They're great for user- or profile-specific settings.
Named Credentials: Use these to define the details of an external system, including the URL and authentication parameters. This centralizes authentication information and prevents you from having to store it directly in your code.
Custom Labels: Store text strings that can be translated into different languages. They are essential for building multilingual applications.
SOQL queries: Querying data directly from standard or custom objects is a flexible way to retrieve values that may change over time, such as a list of active users or specific product information.
Hierarchy Custom Metadata Types: A specific type of custom metadata that allows you to define a hierarchy of settings, providing a cascading approach to configuration based on user or profile.
Summary
Hardcoding record IDs creates brittle, non-portable logic that fails across environments. Replace IDs with dynamic lookups, configurable metadata, or context-aware values. Code Reviews flags this as an Error to ensure your code and automations remain robust, flexible, and deployable.