Skip to main content

Introduction

info

Let's bridge the gap between best practice theory and how we enforce it!

SF Explorer allows you to define and perform simple checks on your orgs Data and Metadata in a simple yet flexible manner.

You can access, run and configure those rules via Devops > Best Practices

example

info

You can run the report at a given date. Above 01/01/2024

UI integration​

Once defined, errors will be showned contextually on your records as you navigate through SF Explorer:

example

Setup Enhancement​

Enhance your Salesforce setup with checks and best practices with a new chrome extension called SF Explorer Advanced Setup

It adds custom message into your Salesforce setup screen to enforce your project rules are enforced. Your Design Authority should be pleased! You can add a custom messages for:

  • New Custom Object

  • New Permission Set Those messages are configurable in the option page.

  • It prevent user from creating duplicate fields

  • It shows similar fields when opening a custom field

example

Command line integration​

It is simple to integrate those rules in your current pipelines, for example with a Github Action:

example

Create a file named .env with the following content:

SFEXP_LOGIN=XXX # remove it to use SFDX instead
SFEXP_PASSWORD=XXX # Password+SecurityToken, remove it to use SFDX instead
LOGINURL=https://login.salesforce.com #or https://test.salesforce.com
DATE=TODAY  #or 2024-01-01
RULES=EntityDefinition,CustomField  #specify to only run rules on EntityDefinition and CustomField - remove param to check all rules

To connect with SFDX, don't use the SFEXP_LOGIN/SFEXP_PASSWORD env var.

Run the command:

npx @sf-explorer/devops.cli

The command will generate an output file name testReport.xml (in JUnit format).

Ignore metadata​

You can ignore specific errors with a file named .sfexplorerignore (using regex similar to a .gitignore file)

  • ignore an author with @ and the author name
  • ignore a record with its type and target

Sample Rules on Basic Entities​

EntityDefinition​

A custom object Name must be in english and PascalCase
A custom object Description is required
Less than 100 custom fields
Maximum one custom trigger per object
Maximum 15 record types per object

CustomField​

A CustomField API Name must be in english and PascalCase
Custom Fields must have a Description (at least 20 chars)

Flow​

Flow Description is required (at least 20 chars)
Flow Label must be Short Yet Meaningful

PermissionSet​

Name is following project convention
Description is required (more than 20 chars)

ApexClass​

An Apex class name must be PascalCase and use a correct Suffix
An ApexClass must follow the best practices
An ApexClass must have a Description
An ApexClass must have an author
Apex variables must be camelCase
Apex methods must be camelCase

LightningComponentResource​

An LWC must have an author
An LWC must have a description

FieldPermissions​

No field level security on Profiles (except System Administrator)

Sample Rules on Omnistudio​

OmniUiCard​

Flexcards names must be pascal case
Flexcards must have a description

OmniProcess​

Omniscript Type should be camel case (for LWC compatibility)
Omniscript SubType must be PascalCase
Omniscripts must have a description
Omniscript must have less than 100 elements

OmniProcessElement​

Remote action and DataRaptor Actions must have a description
Set Values and Set Errors must start with Set+PascalCase
Remote Action must start with 'Invoke+PascalCase'
DataRaptor Extract must start with 'DRE+PascalCase'
DataRaptor Post must start with 'DRP+PascalCase'
DataRaptor Extract must start with 'IP+PascalCase'

OmniDataTransform​

DataRaptors must have a description