Salesforce development standards

Introduction

What is this document?

This Salesforce Development Standards Guide is Vantegrate's official normative framework for building solutions on the Salesforce platform. It defines the conventions, patterns and best practices that guarantee consistent, maintainable, high-quality code across every project.

The document sets clear rules for naming, code structure, the data model, automations, security and documentation. Each standard is backed by concrete examples, drawn from a real electronic-invoicing implementation on Salesforce, so it can be understood and applied immediately.

Who is it designed for?

Salesforce developers: both new members of the Vantegrate team and experienced developers will find here the mandatory conventions for writing code that integrates cleanly with the rest of the Vantegrate ecosystem.

Architects and tech leads: it provides a reference framework for code reviews, design decisions and the evaluation of technical quality.

Generative AI tools: this document is optimized to be consumed by AI assistants such as Agentforce, Cursor, Claude and other code-generation tools.

How to use this document

For human developers

• Read sections 1 and 2 in full before writing any code.
• Consult the specific section for the type of component you are building.
• Use the checklists in section 11 before every commit and deploy.
• Refer to Appendix A as a quick naming reference.

For AI tools

• Include this document (or the relevant sections) in the prompt context.
• Explicitly reference the naming conventions from section 2.
• Require generated code to follow the patterns in sections 3-6.
• Validate the output against the PMD rules in section 8.

Document design principles

1Fundamental Principles

1.1 Fundamental Rule: English Only

Principle: all code, comments, names of variables, methods, classes, objects, fields and technical documentation must be in English.

Reason: English is the industry standard. It eases global collaboration, improves documentation and enables integration with analysis tools.

1.1.1 Distinction between Label and API Name

It is important to distinguish between Label (the value visible to the user) and API Name (the technical name used in code):

• API Name: ALWAYS in English, using PascalCase. It is the technical identifier used in code, formulas, integrations and automations.
• Label: MAY be in the end user's language. It is what the user sees in the Salesforce interface.

1.2 Test-Driven Development (TDD)

The TDD cycle is mandatory for all Apex development:

Coverage requirements

1.3 Quality and Performance

Golden rules (mandatory):

• 🚫 NEVER run SOQL inside loops.
• 🚫 NEVER run DML inside loops.
• ✓ ALWAYS use bulk processing (design for 200+ records).
• ✓ ALWAYS check Field Level Security (FLS).
• ✓ ALWAYS check CRUD permissions before DML operations.
• ✓ ALWAYS declare the sharing model (with sharing / without sharing).
• 📋 Mandatory compliance with critical PMD rules.

1.4 Native-First Principle

Always prioritize native Salesforce solutions, in this order:

2Universal Naming

This section defines the mandatory naming conventions for every Salesforce development component.

2.1 Case Styles

2.1.1 Critical Rule: PascalCase with NO internal underscores

The Vantegrate convention requires PascalCase with no internal underscores for the API names of objects and fields.

2.1.2 Using PascalCase

Apply it to names that represent entities, types or primary structures.

2.1.3 Using camelCase

Apply it to variables, methods, properties and internal elements.

2.1.4 Using UPPER_SNAKE_CASE

Apply it to constants and immutable values.

2.1.5 Using kebab-case

Apply it in HTML references and web attributes.

2.2 Summary table: Case style by component

2.3 Custom Objects

Case style: PascalCase. API Name format: [ObjectName]__c.

Mandatory rules

• USE PascalCase for the API Name.
• USE the singular (Invoice__c, NOT Invoices__c).
• USE descriptive English names.
• Junction Objects: concatenate the names in alphabetical order.
• Do NOT use abbreviations except for standard ones (Id, URL, API).

2.4 Custom Fields

Case style: PascalCase with no internal underscores. API Name format: [FieldName]__c.

2.5 Relationship Fields (Lookup and Master-Detail)

Relationship fields deserve special attention because they define how users "read" the data model.

2.5.1 Single relationship to an object

When an object has ONE relationship to another object, the API Name is simply the name of the target object:

1// Invoice__c has a lookup to Account
2Field API Name: Account__c
3Field Label:    Account

2.5.2 Multiple relationships to the same object

When an object has MULTIPLE relationships to the same object, use the pattern: [Role][ObjectName]__c.

1// Invoice__c has two lookups to Contact
2PrimaryContact__c → Label: Primary Contact
3BillingContact__c → Label: Billing Contact

2.5.3 Common examples of role-based fields

2.6 Junction Objects

A Junction Object implements a many-to-many relationship between two objects.

2.6.1 Naming

Fundamental rule: use a business name, NOT a technical one.

2.6.2 Structure of a Junction Object

1Object: Application__c
2Label: Application | Plural Label: Applications
3
4Master-Detail fields:
5  - Candidate__c   (MD → Candidate__c)
6  - JobPosition__c (MD → JobPosition__c)
7
8Additional fields:
9  - ApplicationDate__c (Date)
10  - Status__c          (Picklist: Pending, Approved, Rejected)

2.6.3 Primary Master-Detail relationship

The first Master-Detail field created becomes the primary relationship. This determines ownership inheritance, cascade delete and Roll-up Summary availability.

2.7 Record Types

DeveloperName: PascalCase, with no __c suffix.
Pattern: [Object][Segment] or [Object][Process].

2.8 Page Layouts

Pattern: [Object] Layout - [Variant].

2.9 Apex Classes

Case style: PascalCase with a descriptive suffix based on the role.

2.10 Apex Methods and Variables

2.11 Triggers

Case style: PascalCase. Format: [ObjectName]Trigger.

2.12 Test Classes and Methods

Test Class: PascalCase → [ClassBeingTested]Test.
Test Method: camelCase → test[Method]_[Scenario]_[Result].

2.13 Validation Rules

Format: [Object]_[Field/Condition]_[RuleType].

2.14 Permission Sets

Permission Set: [Feature/Object]_[AccessLevel].
Permission Set Group: [Role]_Permissions.

2.15 Flows

API Name: PascalCase with underscores as separators.
Variables: camelCase with a type prefix.

2.16 Reports and Dashboards

Report and Dashboard names are visible to end users, so clarity and organization come first.

2.16.1 Report naming

Case style: Title Case with spaces (readable for users).
Format: [Area] – [Descriptive Name] ([Period]).

2.16.2 Dashboard naming

Format: [Area] – Dashboard [Purpose].

2.16.3 Folder naming

Format: [Area/Department] – [Topic].

3Data Model

3.1 Standard Integration Fields

For objects that take part in integrations with external systems (such as COMFIAR, ERPs, etc.):

4Flow Standards

Flows account for roughly 60% of automation development on Salesforce.

4.1 Flow Variables

Case style: camelCase with a type prefix (varB_, varT_, etc.).

4.2 Flow Elements

Decisions

Case style: Sentence case (question in English).

Assignments

Data Elements

4.3 Error Handling

4.4 Flow Performance

Performance checklist:

• Use specific filters in Get Records elements.
• Limit the records returned (use LIMIT).
• Select only the fields you need.
• ONE Get Records per object (consolidate).
• NEVER DML inside loops: use collections.
• SubFlows for reusable logic.
• Maximum 50 elements per Flow.
• Fault paths on critical elements.

5Apex Development and TDD

5.1 Apex Class Structure

1/**
2 * @description Service class for Invoice-related business logic
3 * @author Vantegrate Development Team
4 * @date 2025-12-01
5 */
6public with sharing class InvoiceService {  // PascalCase
7
8    // UPPER_SNAKE_CASE for constants
9    private static final Decimal IVA_RATE = 0.21;
10    private static final Integer MAX_RETRY_COUNT = 3;
11
12    // camelCase for methods
13    public static Decimal calculateTotalWithTax(List<InvoiceLine__c> lines) {
14        // camelCase for variables
15        Decimal subtotal = 0;
16        Decimal taxAmount = 0;
17
18        for (InvoiceLine__c line : lines) {
19            subtotal += line.Amount__c;
20        }
21
22        taxAmount = subtotal * IVA_RATE;
23        return subtotal + taxAmount;
24    }
25}

5.2 Trigger Handler Pattern

The trigger must be minimal and delegate all logic to the handler:

1// Trigger — PascalCase: [Object]Trigger
2trigger InvoiceTrigger on Invoice__c (before insert, after insert) {
3    new InvoiceTriggerHandler().run();
4}

1// Handler — PascalCase: [Object]TriggerHandler
2public class InvoiceTriggerHandler extends TriggerHandler {
3
4    public override void beforeInsert() {
5        InvoiceService.validateInvoices((List<Invoice__c>) Trigger.new);
6    }
7
8    public override void afterInsert() {
9        InvoiceService.sendToComfiar((List<Invoice__c>) Trigger.new);
10    }
11}

6Lightning Web Components (LWC)

6.1 Component Naming

6.2 LWC Best Practices

• Use @api for public properties exposed to parents.
• Use @track only when necessary (reactive objects/arrays).
• Prefer getter methods over @track for computed values.
• Handle errors in wire methods.
• Use ShowToastEvent for user feedback.
• Avoid querySelector: use data-id and template refs.
• Implement loading states for async operations.
• Use UPPER_SNAKE_CASE constants for magic values.

7Security and Permissions

7.1 CRUD and FLS

In the example below, as user applies the checks automatically and you only need to catch the exception:

1Account myAcc = new Account(
2    Name = 'Vantegrate Upgrade',
3    AnnualRevenue = 500000 // Assume this field is read-only
4);
5try {
6    // Automatically validates CRUD, FLS and Sharing Rules
7    insert as user myAcc;
8} catch (DmlException e) {
9    // Robust handling of security errors
10    for (Integer i = 0; i < e.getNumDml(); i++) {
11        if (e.getDmlType(i) == StatusCode.INSUFFICIENT_ACCESS_OR_READONLY) {
12            System.debug('Error: the user does not have permission');
13        } else {
14            System.debug('Other DML error: ' + e.getDmlMessage(i));
15        }
16    }
17}

In the example below, using WITH USER_MODE at the end of the SOQL query runs the checks automatically and you only need to catch the exception:

1try {
2    // The query fails if the user lacks access to 'Phone' or 'Industry'
3    List<Account> accs = [
4        SELECT Id, Name, Phone
5        FROM Account
6        WHERE Industry = 'Technology'
7        WITH USER_MODE
8    ];
9    System.debug('Records retrieved respecting security: ' + accs.size());
10} catch (QueryException e) {
11    // The message indicates which field or permission is missing
12    System.debug('SOQL permission error: ' + e.getMessage());
13}

7.2 Sharing Model

7.3 Security Checklist

• Declare the sharing model in every class.
• Check CRUD before DML operations.
• Check FLS before accessing sensitive fields.
• Use WITH USER_MODE in queries.
• Do not hardcode IDs.
• Sanitize user inputs.
• Use variable binding in SOQL (prevent injection).
• Avoid sensitive information in debug logs.

8PMD Rules

8.1 Critical Rules (Block Deploy)

8.2 Best-Practice Rules

9Versioning and Release Management

9.1 Semantic Versioning

Format: MAJOR.MINOR.PATCH.

9.2 Release Notes

Every release must document:

• Version number and date.
• New features.
• Changes to existing functionality.
• Bug fixes.
• Breaking changes (if any).
• Migration steps (if any).
• Updated dependencies.

10Documentation

10.1 ApexDoc for Classes

1/**
2 * @description Service for invoice lifecycle management and AFIP integration
3 * @author Vantegrate Development Team
4 * @date 2025-12-01
5 * @version 2.0
6 */
7public with sharing class InvoiceService {
8
9    /**
10     * @description Sends invoices to COMFIAR for AFIP authorization
11     * @param invoices List of invoices to process
12     * @return ProcessingResult Results including CAE numbers
13     * @throws IntegrationException When COMFIAR is unavailable
14     * @example
15     * List<Invoice__c> invoices = [SELECT Id FROM Invoice__c];
16     * InvoiceService.sendToComfiar(invoices);
17     */
18    public static ProcessingResult sendToComfiar(List<Invoice__c> invoices) {
19        // Implementation
20    }
21}

10.2 Flow Documentation

Every Flow must include in its Description:

1FLOW NAME: Invoice Authorization Automation
2
3PURPOSE:
4Sends new invoices to COMFIAR for AFIP authorization
5and updates CAE information upon response.
6
7TRIGGER:
8Record-Triggered Flow on Invoice__c (After Insert)
9
10INPUT REQUIREMENTS:
11- Invoice with Customer, InvoiceDate, and at least one Line
12
13ERROR HANDLING:
14- Validation errors: Set ProcessingStatus__c = 'Error'
15- COMFIAR errors: Log to IntegrationLog__c, alert admin
16
17VERSION: 2.0
18LAST MODIFIED: 2025-12-01
19AUTHOR: Vantegrate Development Team

11Checklists and Templates

11.1 Pre-Deployment Checklist

• Every class has coverage ≥ 75%.
• Every test has meaningful assertions.
• PMD reports no critical violations.
• ApexDoc complete on public classes.
• Flows have fault paths on critical elements.
• No SOQL/DML in loops.
• Bulk testing completed (200+ records).
• Names follow the standard conventions.
• Security Review: CRUD/FLS verified.
• Release notes documented.

11.2 Code Review Checklist

• Code in English (variables, methods, comments).
• Correct naming per the standard.
• Triggers delegate to Handlers.
• Classes declare the sharing model.
• No hardcoded IDs.
• Error handling implemented.
• Appropriate logging with LoggingLevel.
• Tests cover positive and negative scenarios.
• Bulk processing implemented.

11.3 New Custom Object Checklist

• API Name in PascalCase and singular.
• Label and Plural Label defined.
• Description completed.
• ExternalId__c field created.
• IsActive__c field created.
• SourceSystem__c field created.
• LastProcessedDateTime__c field created.
• ProcessingStatus__c field created.
• Sharing model configured.
• Permission Sets updated.
• Page Layouts configured.

AAppendix A: Quick Naming Reference Table