flxbl docs
slackGitHub
  • flxbl
  • sfp
  • sfops
  • Overview
  • Getting Started
    • Pre-Requisites
    • Install sfp
    • Configure Your Project
    • Build & Install an Artifact
    • Congratulations!
    • Docker Images
      • sfp-pro
  • CONCEPTS
    • Overview
    • SF CLI vs. SFP
    • Domains
    • Packages
    • Supported package types
      • Unlocked Packages
      • Org-Dependent Unlocked Packages
      • Source Packages
      • Diff Package
      • Data Packages
    • Artifacts
    • Package vs Artifacts
    • Identifying types of a package
    • Dependency management
    • Transitive Dependency Resolution
    • Destructive Changes
  • configuring a project
    • Project structure
    • Setup Salesforce Org
    • Creating a package
    • Defining a domain
    • Release Config
  • BUILDING ARTIFACTS
    • Overview
    • Determining whether an artifact need to be built
    • Building a domain
    • Building an artifact for package individually
    • Limiting artifacts to be built
    • Controlling aspects of the build command
      • Ignoring packages from being built
      • Building a collection of packages together
      • Selective ignoring of components from being built
      • Use of multiple config file in build command
    • Configuring installation behaviour of a package
      • Always deploy a package
      • Skip Install on Certain Orgs
      • Optimized Installation
      • Pre/Post Deployment Script
      • Reconciling Profiles
      • PermissionSet Assignment
      • Updating Picklist
      • Entitlement Deployment Helper
      • Field History & Feed Tracking
      • Aliasfy Packages
        • Aliasfy Packages - Merge Mode
      • State management for Flows
  • Installing an artifact
    • Overview
    • Controlling Aspects of Installation
    • Applying attributes of an artifact
    • BuiltIn Deployment Helpers
      • PermissionSet Group Awaiter
  • publishing and fetching artifacts
    • Publish Artifact
    • Fetching Artifacts
  • Releasing artifacts
    • Overview
    • Release Definitions
    • Generating a release definition
    • Generating a changelog
  • Validating a change
    • Overview
    • Different types of validation
    • Limiting Validation by Domain
    • Controlling validation attributes of a package
      • Skip Testing
      • Skip Coverage Validation
      • Test Synchronously
  • Analysing a Project
    • Overview
    • Duplicate Check
  • Environment Management
    • Pools
      • Scratch Org Pools
        • Defining a pool
        • Setting up your Salesforce Org for Scratch Org Pools
        • Pool Operations
          • Preparing pools
            • Handling dependencies
          • List Scratch Orgs in a pool
          • Fetch a scratch org
          • Delete Pools
      • Sandbox Pools
        • Sandbox Pool Initialization
        • Fetch a Sandbox from Pool
        • Monitor Sandbox Pools
    • Review Environments
      • Commands
        • Fetch a Review Environment
        • Check Review Environment Status
        • Extend a Review Environment
        • Transition Review Environment Status
        • Unassign a Review Environment
      • Considerations
    • Sandbox
      • Create Sandbox
      • Delete Sandbox
      • List Sandbox
      • Login to Sandbox
      • Update Sandbox
  • Development
    • Development Environment
    • Pull Changes from your org
    • Push Changes to your org
    • Dependency Management
      • Expand Dependencies
      • Shrink Dependencies
      • Explain Dependencies
  • Running sfp as a server
    • Introduction
    • sfp-pro-server: Architecture Overview (Alpha)
      • Task Processing System
      • Authentication & Security Architecture
      • Authentication System: Deep Dive
      • Database Architecture
      • Network Architecture and Integration System
      • Integration Architecture: Building Extensions
    • Installing SFP Server
    • Initializing SFP server
  • API Reference
    • Health
    • Authentication
    • Token
    • Salesforce
    • Team
    • Users
    • Tasks
    • Key Value
    • Repository
    • WebHooks
  • Metrics
    • Available Metrics
    • Custom Metrics
    • Configuring Collectors
      • Datadog
      • Splunk
      • New Relic
      • StatsD
  • Helpers
    • Managing Shared Resources
  • Command Guide
    • Core
      • Build
      • Quickbuild
      • Publish
      • Install
      • Release
    • Advanced
      • Validate
      • Artifacts
      • Changelog
      • Impact
      • Pool
      • Metrics
      • Repo
    • Utilities
      • Apex Tests
      • Flow
      • Dependency
      • Profile
  • FAQs
    • Common Errors
      • Org Shapes
      • Troubleshooting Unlocked Packages Build Failure Due to Code Coverage
    • Common Questions
      • Email Templates Deployment: Classic vs Lightning
      • Dealing with Long Build Times in Salesforce
      • Standard ValueSets and unlocked packages
      • Common Issues encountered with aliasfied packages
      • API Version
      • Understanding alwaysDeploy and skipIfAlreadyInstalled in Deployment Pipelines
    • sfp versioning and upgrade Process
  • References
  • Legal
    • Terms of Service for sfp
    • Terms of Service for 'sfp-pro' Software
  • LLMs.txt
Powered by GitBook
On this page
  • Overview
  • How It Works
  • Configuration
  • Understanding Results
  • Understanding Indicators
  • Best Practices
  • Common Scenarios and Solutions
  • Integration with CI/CD
  • Troubleshooting
  1. Analysing a Project

Duplicate Check

sfp-pro
sfp (community)

Availability

✅

❌

From

January 25

The duplicate check functionality helps identify duplicate metadata components across your Salesforce project. This analysis is crucial for maintaining clean code organization and preventing conflicts in your deployment process.

Overview

Duplicate checking scans your project's metadata components and identifies:

  • Components that exist in multiple packages

  • Components in aliasified packages

  • Components in unclaimed directories (not associated with a package)

How It Works

The duplicate checker:

  1. Scans all specified directories for metadata components

  2. Creates a unique identifier for each component based on type and name

  3. Identifies components that appear in multiple locations

  4. Provides detailed reporting with context about each duplicate

Configuration

Duplicate checking can be configured through several flags in the project:analyze command:

sfp project:analyze --fail-on duplicates --fail-on-unclaimed

Key Configuration Options

Option
Description
Default

--show-aliasfy-notes

Show information about aliasified packages

true

--fail-on-unclaimed

Fail when duplicates are in unclaimed packages

false

Understanding Results

The duplicate check provides three types of findings:

  1. Direct Duplicates: Same component in multiple packages

  2. Aliasified Components: Components in aliasified packages (typically expected)

  3. Unclaimed Components: Components in directories (such as unpacakged or src/temp) not associated with packages

Sample Output

# Duplicate Analysis Report

## Aliasified Package Information
- Note: Package "env-specific" is aliasified - duplicates are allowed.

## Component Analysis

### ❌ CustomObject: Account.Custom_Field__c (Duplicate Component)
- `src/package1/objects/Account.object` 
- `src/package2/objects/Account.object`

### ⚠️ CustomLabel: Common_Label (Aliasified Component)
- `src/env-specific/qa/labels/Custom.labels` (aliasified)
- `src/env-specific/prod/labels/Custom.labels` (aliasified)

Understanding Indicators

The analysis uses several indicators to help you understand the results:

  • ❌ Indicates a problematic duplicate that needs attention

  • ⚠️ Indicates a duplicate that might be intentional (e.g., in aliasified packages)

  • (aliasified) Marks components in aliasified packages

  • (unclaimed) Marks components in unclaimed directories

Best Practices

  1. Regular Scanning: Run duplicate checks regularly during development

  2. Clean Package Structure: Keep each component in its appropriate package

  3. Proper Package Configuration: Ensure all directories are properly claimed in sfdx-project.json

  4. Documented Exceptions: Document cases where duplication is intentional

Common Scenarios and Solutions

1. Legitimate Duplicates

Some components may need to exist in multiple packages. In these cases:

  • Use aliasified packages when appropriate

  • Document the reason for duplication

  • Consider creating a shared package for common components

2. Unclaimed Directories

If you find components in unclaimed directories:

  1. Add the directory to sfdx-project.json

  2. Assign it to an appropriate package

  3. Re-run the analysis to verify the fix

3. Aliasified Package Duplicates

Duplicates in aliasified packages are often intentional:

  • Used for environment-specific configurations

  • Different versions of components for different contexts

  • Not considered errors by default

Integration with CI/CD

Integration is limited only to GitHub at the monent, The command needs GITHUB_APP_PRIVATE_KEY and GITHUB_APP_ID to be set in an env variable for the results to be reported as a GitHub check

When integrating duplicate checking in your CI/CD pipeline:

  1. Configure Failure Conditions:

    sfp project:analyze --fail-on duplicates --fail-on-unclaimed --output-format github
  2. Generate Reports:

    sfp project:analyze --report-dir ./reports --output-format markdown
  3. Review Results:

    • Use generated reports for tracking

    • Address critical duplicates

    • Document accepted duplicates

Troubleshooting

  1. False Positives

    • Verify package configurations in sfdx-project.json

    • Check if components should be in aliasified packages

    • Ensure directories are properly claimed

  2. Missing Components

    • Verify scan scope (package, domain, or path)

    • Check file permissions

    • Validate metadata format

Last updated 3 months ago