But already in the phase of creating and working on the actual source and code of the project, automation can come in handy.

For example, it can help to individualize the shaping of development environments in a reproducible way.

SFDX automation, like any technology or system, has certain limitations:

• SFDX automation requires developers to become familiar with the SFDX CLI and the underlying concepts of the Salesforce platform.
• Salesforce applications often have complex dependencies among metadata components. SFDX automation requires developers to manage and deploy these dependencies to avoid issues.
• Although SFDX provides support for many metadata types, some are still not fully supported or not supported at all.
• SFDX automation relies on CLI and network communication with the Salesforce platform, which can introduce latency and impact performance. SFDX automation provides limited control over the management of sandboxes.

Are you looking to leverage SFDX automation to its fullest? We have the solution for you at Hutte.

Hutte has custom buttons

You can access the automation using a custom button, like importing CDATA sets as a no-coder, from Hutte’s visual UI.

Exposing these requests helps contributors run such code bases, reduce their learning curve, and improve their progress by triggering automation from the UI before submitting the code for review.

The fantasy of automation is working in SFDX without any limits. With Hutte, all tasks in your development lifecycle can be automated or assisted by automation.

You can have assisted code reviews by running quality checks automatically before a manual reviewer does their final review and approval step.

Look at how you can visually utilize SFDX through Hutte’s Custom Button Recipes.

Access Hutte’s Recipes

Hutte’s Custom Button Recipes on GitHub are publicly available. We also have mutations for GitLab, Bitbucket, and Azure.

Hutte is truly one of the best tools that we use. Product owners, Salesforce solution architects, business analysts — anyone on our team can easily and visually accomplish the tasks that would otherwise take a lot of clicks, time, and coding.

Sebastian Lechner

Product Management Director of IPfolio
Clarivate

Source: Hutte

Hutte-SFDMU

This custom button offers one way to load seed data.

Prerequisites:

• A valid SFDX project
• A “hutte.yml” file (for example, the default one shown in the “CONFIGURATION” tab)
• A source org authenticated with SFDX locally from which you want to export data.

The following steps assume that you use the data directory to store CSV files.

Step One

Install SFDMU on your machine:

echo y | sfdx plugins install sfdmu
sfdx sfdmu --help

Step Two

Prepare the “data/export.json” file:

{
  "objects": [
    {
      "query": "SELECT readonly_false FROM Account ORDER BY Name ASC",
      "operation": "Upsert",
      "externalId": "Name"
    },
    {
      "query": "SELECT readonly_false FROM Contact ORDER BY Email,LastName,FirstName ASC",
      "operation": "Upsert",
      "externalId": "Email;LastName;FirstName"
    }
  ],
  "excludeIdsFromCSVFiles": true
}

Add the following lines to the “.gitignore” file:

# SFDMU
/data/source/
/data/target/
/data/logs/

Export the data from an org to the Git repository:

sfdx sfdmu run -s "<THE_TARGET_ORG_ALIAS>" -u csvfile --filelog 0 -n
git add data
git commit -m "add Salesforce data"
git push

Step Three

• Edit the “hutte.yml” file in your default branch
• Add the following button in “custom_scripts > scratch_org:”

custom_scripts:
  scratch_org:
    "Import Data":
      description: "Import data using SFDMU"
      run: |
        echo y | sfdx plugins install sfdmu
        sfdx plugins
        sfdx sfdmu run -p data -s csvfile -u "${SALESFORCE_USERNAME}" --filelog 
0 -n

Step Four

• Create a scratch org or open an existing one
• Verify that the button is displayed.

Hutte-PMD

This is a custom button that would trigger static code analysis.

Prerequisites:

• A GitHub repository with a valid SFDX project
• A “hutte.yml” file (for example, the default one shown in the “CONFIGURATION” tab).

Step One

Create the following three files:

File One: “apex-pmd-ruleset.xml”

<?xml version="1.0"?>
<ruleset name="Ruleset for Apex"
         xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd">
    <description>Ruleset for Apex</description>
    <rule ref="category/apex/bestpractices.xml/ApexUnitTestShouldNotUseSeeAllDataTrue" />
    <rule ref="category/apex/errorprone.xml/AvoidHardcodingId" />
</ruleset>

File Two: “.github/workflows/pmd.yml”

name: Run PMD
on:
  workflow_dispatch:
  workflow_call:
jobs:
  default:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Install PMD
        run: |
          npm install --global pmd-bin
          pmd --version
      - name: Run PMD
        run: |
          pmd -language apex -R apex-pmd-ruleset.xml -dir force-app

File Three: “.github/workflows/main.yml”

name: main
on:
  push:
    branches:
      - main
jobs:
  pmd:
    name: Run PMD Workflow
    uses: ./.github/workflows/pmd.yml
    secrets: inherit

Step Two

• Edit the “hutte.yml” file in your default branch
• Add the following custom script/button named “Run PMD” in “custom_scripts > scratch_org:”

custom_scripts:
  scratch_org:
    "Run PMD": |
      npm install --global pmd-bin
      pmd --version
      pmd -language apex -R apex-pmd-ruleset.xml -dir force-app

Cook up some customer buttons

Enjoy convenience, peace of mind, and the ultimate script or button customization.