Source tracking is a Salesforce feature that automatically records every metadata change in an environment and maps it to version-controlled files, so each admin click and code edit becomes reviewable Git history. Undocumented metadata changes create compliance gaps that surface during audits: when a field is renamed in a sandbox or an Apex trigger is edited directly in production, the change often bypasses traditional change-set workflows, forcing expensive forensic analysis during SOX, GDPR, or SOC 2 reviews.

This guide shows how to enable source tracking in Salesforce, capture changes, and integrate them into CI/CD workflows that satisfy compliance teams. It covers both ways to turn it on, per sandbox and org-wide through Dev Hub, the permissions you need, and the current Salesforce CLI commands.

Why Source Tracking in Salesforce Matters for Compliance

Source tracking captures metadata changes (additions, deletions, modifications) inside a Salesforce environment and maps them to version control files, automatically logging each component change the moment it happens to create an immutable audit trail.

Supported environments:

• Scratch orgs: source tracking is on automatically.
• Developer and Developer Pro sandboxes: opt-in, enabled in Setup.
• Partial Copy, Full, and production: not supported.

Source tracking differs fundamentally from change sets. The table below shows why it fits modern, compliant workflows where change sets fall short.

The compliance payoff is immediate: SOX auditors get proof of who changed financial logic, GDPR teams get data lineage, and SOC 2 assessments get timestamped, user-level logs without manual spreadsheets.

The cost of not having this shows up during audits. Without an automatic record, teams reconstruct months of undocumented changes by hand, cross-checking sandboxes against production and hoping nothing was missed. Source tracking replaces that scramble with a continuous, defensible record that maps each change to a person, a timestamp, and a commit.

1. Prepare Your Environment and Version Control

Before enabling source tracking, confirm your development setup can capture and process metadata changes. Start by checking that your Salesforce CLI is current, then authenticate to your target environment with a meaningful alias.

# Check your Salesforce CLI version (use the modern sf CLI)
sf --version

# Authenticate to your sandbox with a memorable alias
sf org login web --alias DevSandbox --instance-url https://test.salesforce.com

Note that the modern Salesforce CLI uses the sf executable; the older sfdx force:source:* commands are deprecated. The alias becomes critical when you manage multiple environments, since you will reference it in later commands.

Finally, structure your Git repository to support automated change detection:

• Store metadata under the force-app directory to match Salesforce DX standards.
• Commit your sfdx-project.json so the team shares the same namespace and API version settings.
• Use feature branches that merge to develop, then main, for clean deployment histories.

This structure ensures that when you preview changes later, you get clear diffs instead of confusing path mismatches.

2. Enable Source Tracking

How you enable source tracking depends on the environment. Scratch orgs get it automatically. Developer and Developer Pro sandboxes are opt-in, and you can turn tracking on one sandbox at a time or org-wide through Dev Hub, covered in the next section. Once active, source tracking captures declarative changes such as custom fields, validation rules, and flows, alongside code such as Apex classes, triggers, and Lightning components.

Scratch Environments

Source tracking is enabled automatically when a scratch org is created, so these environments carry a complete audit trail from the start. Confirm tracking is working by previewing changes.

# Preview tracked changes to confirm source tracking is active
sf project deploy preview --target-org MyScratch

Developer / Developer Pro Sandboxes

These sandboxes require manual setup, with one timing caveat: source tracking only captures changes made after you enable it. If your sandbox already contains customizations you need to track, capture a baseline first.

1. Log in to the sandbox and go to Setup, then Sandbox Settings.
2. Select Enable Source Tracking in This Sandbox and save.
3. Refresh the sandbox to fully activate tracking.

The refresh step is mandatory; without it, tracking stays dormant even though the setting looks enabled. A few limits to plan around:

• Historical blind spots: changes made before enabling tracking will not appear, so capture a baseline through metadata retrieval first.
• Refresh resets: each refresh clears tracking history and requires re-enabling, and teams often forget, creating audit gaps.
• Re-enable delay: if you disable source tracking, it can take several days for the tracking records to clean up before you can re-enable it, so avoid toggling it off casually.
• Environment gaps: Partial Copy, Full, and production do not support source tracking at all, exactly where audit trails matter most.

These constraints lead many enterprises to supplement native tracking with a DevOps platform that maintains audit coverage across every environment type.

Enable Source Tracking for All Sandboxes at Once (Dev Hub Method)

Enabling tracking one sandbox at a time does not scale. If you manage many sandboxes, turn it on once at the org level so every new and refreshed Developer and Developer Pro sandbox uses it automatically.

1. In your production org, go to Setup and open Dev Hub.
2. Enable the option to turn on source tracking for Developer and Developer Pro sandboxes.

Once set, all newly created and refreshed Developer and Developer Pro sandboxes use source tracking automatically. Existing sandboxes keep their current tracking state until their next refresh, so you do not lose coverage the moment you flip the switch. For teams running dozens of sandboxes, this is the practical, scalable path, and it is the method most competitor guides skip. Use the per-sandbox method when you only need tracking on one or two environments; use the Dev Hub method when you are standardizing across a team.

Permissions Required

Source tracking setup runs into permission errors more often than search queries. Here is what you need before you start.

If you cannot see the Sandbox Settings or Refresh options, you are most likely missing one of these permissions; ask your admin to assign them. A common stumbling block: the option to enable tracking or refresh a sandbox simply does not appear for users who lack these permissions, so it reads like a missing feature rather than an access issue. Checking permissions first saves a support ticket.

3. Integrate Source Tracking Into CI/CD Workflows

Source tracking becomes compliance-ready only when integrated into disciplined workflows and automated pipelines. The combination turns scattered metadata changes into verifiable audit trails.

Establish development workflow discipline

Daily discipline ensures source tracking captures every change. Before starting new work, preview what has changed in the org since your last sync, pull those changes locally, commit with a message that links to a requirement, then deploy to shared environments for integration testing.

# 1. See what changed in the org since your last sync
sf project retrieve preview

# 2. Pull only the tracked changes into your local project
sf project retrieve start

# 3. Commit with a message that links to a requirement
git commit -m "US-1347 | add sharing logic to Account trigger"

# 4. Deploy to a shared environment for integration testing
sf project deploy start

Previewing first prevents configuration drift; retrieving only tracked items keeps version control clean; and the commit message creates a chronological chain of custody from requirement to deployment.

Run this loop daily rather than saving it for release week. Small, frequent syncs keep your local project aligned with the org, make conflicts easier to resolve, and ensure the audit trail reflects reality instead of a rushed end-of-sprint reconstruction.

Automate pipeline integration

Automated pipelines turn disciplined tracking into verifiable deployment packages, validating only changed components and promoting them through environments. The Salesforce CLI translates tracked changes into deployable artifacts through standard automation platforms. This GitHub Actions example validates with a dry run, then deploys.

name: Salesforce Deploy
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Salesforce CLI
        run: npm install --global @salesforce/cli
      - name: Authorize org (JWT)
        run: |
          sf org login jwt \
            --client-id ${{ secrets.CONSUMER_KEY }} \
            --jwt-key-file server.key \
            --username ${{ secrets.SF_USERNAME }} \
            --instance-url https://test.salesforce.com \
            --set-default
      - name: Validate (dry run) then deploy tracked changes
        run: |
          sf project deploy start --source-dir force-app --dry-run
          sf project deploy start --source-dir force-app

Each run links deployments to specific Git commits and consolidates logs, test results, and deployment evidence, so every deployment maps to tracked source changes. Because the pipeline validates before it deploys, non-compliant or breaking changes fail the dry run instead of reaching a shared environment. Storing the run's logs and test results alongside the commit gives auditors a single, linked record for every promotion.

Compliance integration benefits

This approach adds automated gates that keep non-compliant code out of production while generating the approval and test-coverage documentation SOX, GDPR, and SOC 2 require. Pipeline logs become audit evidence, and Git history provides the chronological change record regulators expect. Because the evidence is generated as a byproduct of how you already deploy, compliance stops being a separate, manual project and becomes a property of the pipeline itself.

4. Convert Tracking Data Into Compliance Reports

Source tracking provides the raw audit trail, but compliance teams need formatted reports that map changes to requirements. The reporting process has three steps: export tracking data, cross-reference with deployment artifacts, and store evidence in a tamper-proof format. To start, export the current tracking status as structured JSON.

# Export the current tracking status as structured JSON for evidence
sf project deploy preview --json

Cross-reference this output with build artifacts from your CI server, such as deployment logs, test results, and approval records. Combine them into comprehensive audit packages, then store the evidence in read-only repositories where auditors can verify commit signatures against actual deployments. This creates an immutable chain of custody from code change to production release.

Map each exported change to the control it supports so auditors can trace a requirement to its evidence quickly. A consistent structure here, one export format, one storage location, one tagging convention, is what turns raw tracking data into a report you can hand over without a week of preparation.

Compliance-focused practices:

• Automate nightly exports of tracking status for continuous evidence collection.
• Use Git tags for compliance-sensitive releases (such as sox-fy26-q2) to speed audit responses.
• Document tracking re-enablement after sandbox refreshes to explain any gaps.
• Centralize tracking logs with broader compliance dashboards for streamlined audits.

Establishing Continuous Compliance Through Source Tracking

Native source tracking gives you a clean audit trail in scratch orgs and Developer sandboxes, but it stops at Partial Copy, Full, and production, exactly the environments auditors scrutinize most. That gap is where a dedicated DevOps platform earns its place: it extends source tracking and audit-ready reporting across every environment, with a Salesforce-native deployment option that keeps governance close to your org.

To go beyond the native checkbox, see how Flosum handles DevOps and audit trails across your full Salesforce landscape, and request a demo to see it against your own environments.

Frequently Asked Questions (FAQ)