Salesforce Naming Conventions

 Salesforce has specific naming conventions for different elements to ensure consistency, readability, and maintainability in your code and configuration. Following these conventions also makes it easier for developers and administrators to collaborate. Here are some key naming conventions in Salesforce:

1. Classes, Interfaces, and Triggers

  • Naming Format: Use CamelCase (uppercase first letter for each word).
  • Class Names: Should be descriptive and convey the purpose of the class.
  • Example:
    • AccountHandler
    • LeadService
    • OpportunityTriggerHelper

2. Methods and Variables

  • Naming Format: Use camelCase (lowercase first word, uppercase for subsequent words).
  • Method Names: Should clearly state the action or purpose.
  • Example:
    • calculateTotalPrice
    • updateLeadStatus
  • Variable Names: Should describe the data they store.
  • Example:
    • totalAmount
    • isActive

3. Constants

  • Naming Format: Use ALL_CAPS_WITH_UNDERSCORES.
  • Example:
    • MAX_RETRIES
    • DEFAULT_TIMEOUT

4. Custom Objects

  • Naming Format: Use PascalCase (uppercase first letter of each word, no spaces or underscores).
  • Object Names: Should be singular (best practice) and descriptive of the object.
  • API Name: Automatically ends with __c to signify it is custom.
  • Example:
    • Invoice__c
    • PaymentSchedule__c

5. Custom Fields

  • Naming Format: Use PascalCase (for API name) and descriptive names.
  • API Name: Ends with __c to denote it is custom.
  • Example:
    • TotalAmount__c
    • DueDate__c
  • Field Labels: Can have spaces and should be more readable for users.
    • Example: Total Amount, Due Date

6. Custom Relationships

  • Lookup Relationships:
    • Field API Name: Ends with __r for relationships.
    • Example: Account__r
  • Master-Detail Relationships:
    • Parent-Child Field API Names: Should be descriptive of the relationship.
    • Example: Account__r, Orders__r

7. Triggers

  • Naming Format: Use ObjectNameAction format to indicate the object and the action/event.
  • Example:
    • AccountBeforeInsert
    • LeadAfterUpdate
    • OpportunityBeforeDelete

8. Test Classes

  • Naming Format: Use ClassNameTest format.
  • Example:
    • AccountHandlerTest
    • OpportunityServiceTest

9. Apex Properties

  • Naming Format: Use camelCase.
  • Example:
    • isValid
    • totalRecords

10. Visualforce Pages and Components

  • Naming Format: Use PascalCase for the names of pages and components.
  • Example:
    • OrderSummaryPage
    • LeadInfoComponent

11. Lightning Components (Aura/LWC)

  • Component Names: Use camelCase for component names.
  • Bundle Names: Should be descriptive.
  • Example:
    • accountInfo
    • orderSummary

12. SOQL Queries

  • Aliases: Use lowercase and descriptive aliases in SOQL.
  • Example:
    • SELECT Id, Name FROM Account a WHERE a.Industry = 'Tech'

13. Permissions, Profiles, and Roles

  • Naming Format: Use PascalCase and ensure the name reflects the role or permission.
  • Example:
    • SalesManager
    • FinanceAdmin

14. Reports and Dashboards

  • Naming Format: Use PascalCase and ensure the name reflects the content of the report or dashboard.
  • Example:
    • SalesPerformanceReport
    • MonthlyRevenueDashboard

Best Practices

  • Avoid Abbreviations: Unless widely understood, avoid abbreviating words in your names.
  • Be Descriptive: Make names descriptive enough to convey the purpose without being overly verbose.
  • Consistency: Follow the same naming style across all elements for consistency.

By adhering to these conventions, you’ll make your Salesforce setup more readable, maintainable, and easier for other team members to understand and work with.

Comments

Post a Comment

Popular posts from this blog

API Names in Salesforce

 In Salesforce, an API Name is a unique identifier for metadata components like fields, objects, or custom settings that enables external systems, scripts, and integrations to reference Salesforce data programmatically. The API name remains consistent, even if the label displayed in the user interface changes, making it essential for maintaining integration stability. Key Characteristics of API Names Field and Object API Names : Standard object and field API names generally mirror their label names, but with spaces removed. Custom fields and objects have the suffix __c , denoting them as custom. Example: A custom object called "Project" would have an API name of Project__c . A custom field called "Start Date" on the Project object would have an API name of Start_Date__c . Case-Sensitivity : API names in Salesforce are case-sensitive , so it’s essential to match them exactly when using them in code or integrations. Usage : API names are used in SOQL queries, Apex co...
Read more

18 - LWC - BEST PRACTICES - For accessing HTML elements and their values in JavaScript

 In Lightning Web Components (LWC) , best practices for accessing HTML elements and their values in JavaScript involve using template.querySelector , template.querySelectorAll , and data-* attributes. Here’s a guide to help you follow these best practices effectively: 1. Use template.querySelector and template.querySelectorAll Since IDs can be unpredictable in LWC , the template.querySelector method is generally preferred. You can use CSS selectors , including class names, tag names, and data-* attributes, to locate elements. html Copy code <!-- template.html --> < lightning-input class = "my-input" data-id = "specialInput" value = "Sample Value" > </ lightning-input > javascript Copy code // component.js // Accessing the element const inputElement = this . template . querySelector ( '.my-input' ); // Getting the value const inputValue = inputElement. value ; 2. Use data-* Attributes for Specific Identifiers For ele...
Read more

6 - Object Relationships (Lookup and Master-Detail and Junction Objects)

 Here's a tabular comparison of the Lookup and Master-Detail relationship types in Salesforce: Feature Lookup Relationship Master-Detail Relationship Definition and Usage Loosely coupled; records are linked but can exist independently Tightly coupled; child record depends on the parent for existence Data Integrity and Ownership Child record does not inherit parent’s sharing or ownership Child inherits sharing, permissions, and ownership from the parent Roll-up Summary Fields Not available Available; aggregates values from child to parent Required Field Optional; child can exist without a parent Required; child must have a parent Cascade Delete Optional (not automatic) Automatic; deleting parent deletes all related child records Security and Access Child has independent sharing settings Child inherits sharing settings from the parent Hierarchy Depth Flexible; supports multi-level relationships Limited to strict parent-child hierarchy with up to two relationships This structure pro...
Read more