This plugin is still in beta and under active development. Command signatures may be subject to change.
The plugin is not digitally signed, so in order to avoid the prompt on installation, add it to your unsignedPluginAllowList.json. If you don't mind the prompt, simply run:
sf plugins install @j-schreiber/sf-pluginContributers are welcome! Please reach out on Linkedin or via Email.
Check out the GitHub Wiki for in-depth documentation of concepts and technical limitations. Here's the exhaustive command reference.
sf jsc apex schedule exportsf jsc apex schedule managesf jsc apex schedule startsf jsc apex schedule stopsf jsc data exportsf jsc maintain field-usage analysesf jsc maintain flow-export obsoletesf jsc maintain flow-export unusedsf jsc maintain garbage collectsf jsc manifest rolloutsf jsc manifest validate
List all scheduled jobs on the target org.
USAGE
$ sf jsc apex schedule export -o <value> [--json] [--flags-dir <value>] [-c <value>] [-j <value>] [-d <value>]
[--concise]
FLAGS
-c, --apex-class-name=<value> Only list jobs from a specific apex class.
-d, --output-dir=<value> Writes exported jobs to a config file that can be used with "manage" command.
-j, --job-name=<value> Only list jobs with a specific job name. Supports partial matches.
-o, --target-org=<value> (required) Target org to check.
--concise Minimize columns displayed in output table.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
List all scheduled jobs on the target org.
Export all jobs currently scheduled on the target org or specify additional filters to narrow down search results.
EXAMPLES
List all jobs on the target org
$ sf jsc apex schedule export -o MyTargetOrg
List jobs that match apex class and job name
$ sf jsc apex schedule export -o MyTargetOrg -c MyScheduledJobClass -n "Scheduled Job Name"
List jobs that start with "Auto" and export them to tmp/dev/jobs.yaml
$ sf jsc apex schedule export -j "Auto" -d tmp/dev
See code: src/commands/jsc/apex/schedule/export.ts
Manages all cron jobs on a target org from config file.
USAGE
$ sf jsc apex schedule manage -o <value> -f <value> [--json] [--flags-dir <value>] [--dry-run]
FLAGS
-f, --config-file=<value> (required) Path to a valid config file that configures scheduled jobs.
-o, --target-org=<value> (required) Target org where the job will be scheduled.
--dry-run Simulate a run and get information on how many jos would be started, stopped, and left
untouched.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Manages all cron jobs on a target org from config file.
Provide the path to a config file that contains a definition of scheduled jobs. The manage command will try to start
non-existing jobs and, depending on options, also stop obsolete running jobs. All options for this command are read
from the config file.
EXAMPLES
Sync all jobs on target org with config file
$ sf jsc apex schedule manage -o MyTargetOrg -f scheduled-job-definitions.yaml
FLAG DESCRIPTIONS
-f, --config-file=<value> Path to a valid config file that configures scheduled jobs.
Specify the jobs to start, together with options how obsolete or redundant jobs should be treated. Jobs are
identified by their unique job name. You can specify the same apex class multiple times, as long as job names are
different. For convenience, you can also use the apex class as job name and omit class property - in that case, you
can only schedule an apex class once for obvious reasons.
--dry-run Simulate a run and get information on how many jos would be started, stopped, and left untouched.
Queries existing jobs on the target org and evaluates, which jobs would be changed. However, dry-run cannot compile
the apex class and cron expression. This means, that invalid cron expressions or apex classes will not be caught and
the command may still fail, when run without this flag.
See code: src/commands/jsc/apex/schedule/manage.ts
Schedule a cron job on the target org.
USAGE
$ sf jsc apex schedule start -o <value> -c <value> -e <value> [--json] [--flags-dir <value>] [-n <value>] [--trace]
FLAGS
-c, --apex-class-name=<value> (required) Name of the Apex class to schedule.
-e, --cron-expression=<value> (required) The cron expression that specifies execution of the job.
-n, --name=<value> Unique name of the cron job.
-o, --target-org=<value> (required) Target org where the job will be scheduled.
--trace Log detailed debug information of command execution.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Schedule a cron job on the target org.
Provide the name of an apex class that implements the `Schedulable` interface and a cron expression to schedule a cron
job (`CronTrigger`). Use the official Documentation to learn more about cron expressions:
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_scheduler.htm.
EXAMPLES
Schedule a class to run every day at 1 am:
$ sf jsc apex schedule start -c MyJobImplementationName -e '0 0 1 * * ?'
Schedule a class to run on weekdays (Monday to Friday) at 10 am:
$ sf jsc apex schedule start -c MyJobImplementationName -e '0 0 10 ? * MON-FRI'
Schedule a job with a custom name to run every day at 5:30pm:
$ sf jsc apex schedule start -c MyJobImplementationName -e "0 30 17 * * ?" -n "My Job Name"
FLAG DESCRIPTIONS
-c, --apex-class-name=<value> Name of the Apex class to schedule.
Must implement the System.Schedulable interface.
-e, --cron-expression=<value> The cron expression that specifies execution of the job.
Provide the expression in unix-compatible format (see Apex Documentation for more details). The basic syntax of the
expression is "Seconds Minutes Hours Day_of_month Month Day_of_week Optional_year". See examples for commonly used
cron expressions.
-n, --name=<value> Unique name of the cron job.
If you leave this empty, the name of the apex class is used. Jobs must be unique by name: Use different names if you
plan to schedule the same apex class multiple times.
--trace Log detailed debug information of command execution.
Due to limitations of available Salesforce APIs, this command uses an anonymous apex execution under the hood. The
execution may fail due to a variety of reasons, and the scheduler tries its best to extract the correct error
messages. If this doesn't help, use the --trace flag to output full debug logs from the execution.
See code: src/commands/jsc/apex/schedule/start.ts
Stop one or more cron jobs on the target org.
USAGE
$ sf jsc apex schedule stop -o <value> [--json] [--flags-dir <value>] [-c <value>] [-i <value>...] [-n <value>] [--trace]
[--no-prompt]
FLAGS
-c, --apex-class-name=<value> Name of an apex class to stop.
-i, --id=<value>... The CronTrigger Id of the job to stop.
-n, --name=<value> Identify the scheduled job by its provided name.
-o, --target-org=<value> (required) Target org where the job will stopped.
--no-prompt Don't prompt before performing destructive changes.
--trace Log detailed debug information of command execution.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Stop one or more cron jobs on the target org.
The command allows to stop one or more scheduled jobs, based on the provided inputs. You can provide the name of an
apex class, the name of a scheduled job or a list of ids (08e). The command is idempotent: That means it succeeds,
even if no job was actually stopped. If you provide multiple filters (e.g. an apex class and an id), all jobs that
satisfy at least one of the criteria are stopped.
EXAMPLES
Stop all scheduled jobs on a target org
$ sf jsc apex schedule stop -o MyTargetOrg
Stop a job by its id on your default org
$ sf jsc apex schedule stop -i 08e9b00000KktvqAAB
Stop all scheduled jobs of a particular apex class on a target org
$ sf jsc apex schedule stop -c MyCaseReminderJob -o MyTargetOrg
FLAG DESCRIPTIONS
-c, --apex-class-name=<value> Name of an apex class to stop.
The command finds all scheduled instances of this apex class and stops them.
-i, --id=<value>... The CronTrigger Id of the job to stop.
Provide the Id of the cron trigger that was returned by `System.schedule`. If the Id is invalid, an error is
returned. You can add this flag multiple times to specify multiple jobs.
--no-prompt Don't prompt before performing destructive changes.
Without this flag, the command asks for confirmation before stopping them. Use this flag in CI pipelines.
--trace Log detailed debug information of command execution.
Due to limitations of available Salesforce APIs, this command uses an anonymous apex execution under the hood. The
execution may fail due to a variety of reasons, and the scheduler tries its best to extract the correct error
messages. If this doesn't help, use the --trace flag to output full debug logs from the execution.
See code: src/commands/jsc/apex/schedule/stop.ts
Export all data from a plan definition.
USAGE
$ sf jsc data export -o <value> -p <value> [--json] [--flags-dir <value>] [-d <value>] [--validate-only]
[--api-version <value>]
FLAGS
-d, --output-dir=<value> Output directory to export all fields.
-o, --source-org=<value> (required) The source org from where data is exported.
-p, --plan=<value> (required) Path to the plan file that defines the export.
--api-version=<value> Override the api version used for api requests made by this command
--validate-only Does not retrieve records. Only validates the plan.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Export all data from a plan definition.
Takes a plan definition and exports all data from the source org. The created files are
compatible with the "data import tree" command. Lookups are automatically resolved to
referenceIds to retain relationships. This command allows tree exports that are orders
of magnitute more complex than the basic "data export tree".
EXAMPLES
$ sf jsc data export
See code: src/commands/jsc/data/export.ts
Analyse the utilisation of fields for one or more sobjects.
USAGE
$ sf jsc maintain field-usage analyse -s <value>... -o <value> [--json] [--flags-dir <value>] [--custom-fields-only]
[--exclude-formulas] [--check-defaults] [--check-history] [--segment-record-types] [--verbose] [--api-version
<value>] [-r human|csv|markdown]
FLAGS
-o, --target-org=<value> (required) Username or alias of the target org, where analysis is run.
-r, --result-format=<option> [default: human] Change the display formatting of output tables.
<options: human|csv|markdown>
-s, --sobject=<value>... (required) The name of an sobject to analyse.
--api-version=<value> Override the api version used for api requests made by this command
--check-defaults Checks if values differ from defaults.
--check-history Run additional checks with field history (if enabled)
--custom-fields-only Only analyse custom fields.
--exclude-formulas Only analyse non-formula fields.
--segment-record-types Segments the analysis by Record Types.
--verbose Display a table of fields that were ignored during analysis.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Analyse the utilisation of fields for one or more sobjects.
Retrieves the total number of records for an sobject, then each filterable field is analysed
for how many records have a "non nullish" value. The following field types are supported:
textarea, string, multipicklist, picklist, id, reference, date, datetime, time, boolean, phone, email, url, int,
double, currency, percent.
EXAMPLES
Analyse all fields for Account and MyCustomObject__c object
$ sf jsc maintain field-usage analyse -o MyTargetOrg -s Account -s MyCustomObject__c
Analyse only custom fields for Account object
$ sf jsc maintain field-usage analyse -o MyTargetOrg -s Account --custom-fields-only
Analyse all fields, but exclude formulas for Order object
$ sf jsc maintain field-usage analyse -o MyTargetOrg -s Order --exclude-formulas
FLAG DESCRIPTIONS
-r, --result-format=human|csv|markdown Change the display formatting of output tables.
Changes output format of table results that are printed to stdout. Use a format that is easier to copy-paste or
export into other programs that support the format. For example, use markdown to copy-paste table outputs to
Obsidian or Confluence.
-s, --sobject=<value>... The name of an sobject to analyse.
Specify this flag multiple times to analyse multiple sobjects with a single command execution.
Use the full API name of the object.
--check-defaults Checks if values differ from defaults.
Performs an additional check for all fields that have a default value configured. If the field has a default value
configered,
the analysis only counts a field as populated, if the value is different from the default. The analysis algorithm
for fields
without a default value does not change.
The default values of record types are not analysed.
--check-history Run additional checks with field history (if enabled)
Analyses history tracking for this field and checks total number of changes and the date time of the last change. If
history
tracking is not enabled for the SObject, this flag has no effect.
--custom-fields-only Only analyse custom fields.
If omitted, the command analyses standard fields and custom fields of an object.
--exclude-formulas Only analyse non-formula fields.
If omitted, the command analyses all field types, regardless if it is a calculated fields or not.
If a field is calculated (a formula field), the type shows "formula (return value)".
--segment-record-types Segments the analysis by Record Types.
Segmentation will run all checks per record type of the sobject. If the sobject does not have record types enabled,
it will have
no effect. All records are returned as "Master". The analysis (output tables and JSON result) is grouped by record
type developer name.
Segmentation significantly increases the number of API calls.
--verbose Display a table of fields that were ignored during analysis.
Depending on the flags that were used (--custom-fields-only, --exclude-formulas) and the existing fields on the
sobject,
some fields are ignored during analysis. For more information on those fields, use this flag.
See code: src/commands/jsc/maintain/field-usage/analyse.ts
Exports unpackaged obsolete flows from a target org.
USAGE
$ sf jsc maintain flow-export obsolete -o <value> [--json] [--flags-dir <value>] [-f PackageXML|DestructiveChangesXML -d <value>]
[--concise] [--api-version <value>]
FLAGS
-d, --output-dir=<value> Path where package manifests will be created.
-f, --output-format=<option> Specify in which manifest file the content is written.
<options: PackageXML|DestructiveChangesXML>
-o, --target-org=<value> (required) Target org to analyse.
--api-version=<value> Override the api version used for api requests made by this command
--concise Summarize flow output table.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Exports unpackaged obsolete flows from a target org.
Finds and exports inactive (Obsolete or Draft) versions of unpackaged flows. The active version is never included.
This is a complimentary command to the garbage collector, which exclusively analyses packaged flows.
EXAMPLES
Analyse MyTargetOrg and export all obsolete flow versions to destructiveChanges.xml in directory tmp/dev-obsolete.
$ sf jsc maintain flow-export obsolete -o MyTargetOrg --output-dir tmp/dev-obsolete --output-format \
DestructiveChangesXML
Analyse MyTargetOrg and print a table with all obsolete flow versions
$ sf jsc maintain flow-export obsolete -o MyTargetOrg
FLAG DESCRIPTIONS
-d, --output-dir=<value> Path where package manifests will be created.
When provided, creates manifest file (package.xml) at the target location with all exported content. Use the
--output-format flag to write contents to destructiveChanges.xml.
-f, --output-format=PackageXML|DestructiveChangesXML Specify in which manifest file the content is written.
The default option prepares a package.xml with all exported components. If you specify DestructiveChangesXML, the
command creates an empty package.xml and writes all components into destructiveChanges.xml. This flag only has an
effect, if the output directory is set. No source is retrieved or deployed.
--concise Summarize flow output table.
Instead of showing individual exported flow versions, show aggregated information with the flow name and the total
number of versions. Only modifies the formatted output table, not the JSON output or generated package manifests.
See code: src/commands/jsc/maintain/flow-export/obsolete.ts
Exports unpackaged unused flows from a target org.
USAGE
$ sf jsc maintain flow-export unused -o <value> [--json] [--flags-dir <value>] [-f PackageXML|DestructiveChangesXML -d <value>]
[--concise] [--api-version <value>]
FLAGS
-d, --output-dir=<value> Path where package manifests will be created.
-f, --output-format=<option> Specify in which manifest file the content is written.
<options: PackageXML|DestructiveChangesXML>
-o, --target-org=<value> (required) Target org to analyse.
--api-version=<value> Override the api version used for api requests made by this command
--concise Summarize flow output table.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Exports unpackaged unused flows from a target org.
Finds versions from completely inactive flows that are not part of a package. The export contains all versions of the
inactive flow. This is a complimentary command to the garbage collector, which exclusively analyses packaged flows.
EXAMPLES
Analyse MyTargetOrg and export all unused flow versions to destructiveChanges.xml in tmp.
$ sf jsc maintain flow-export unused -o MyTargetOrg --output-dir tmp --output-format DestructiveChangesXML
Analyse MyTargetOrg and print a table with all unused flow versions
$ sf jsc maintain flow-export unused -o MyTargetOrg
FLAG DESCRIPTIONS
-d, --output-dir=<value> Path where package manifests will be created.
When provided, creates manifest file (package.xml) at the target location with all exported content. Use the
--output-format flag to write contents to destructiveChanges.xml.
-f, --output-format=PackageXML|DestructiveChangesXML Specify in which manifest file the content is written.
The default option prepares a package.xml with all exported components. If you specify DestructiveChangesXML, the
command creates an empty package.xml and writes all components into destructiveChanges.xml. This flag only has an
effect, if the output directory is set. No source is retrieved or deployed.
--concise Summarize flow output table.
Instead of showing individual exported flow versions, show aggregated information with the flow name and the total
number of versions. Only modifies the formatted output table, not the JSON output or generated package manifests.
See code: src/commands/jsc/maintain/flow-export/unused.ts
Collect garbage on your org and export to json or package.xml for more actions.
USAGE
$ sf jsc maintain garbage collect -o <value> [--json] [--flags-dir <value>] [-v <value>] [-m <value>...] [-p <value>...] [-f
PackageXML|DestructiveChangesXML -d <value>] [--api-version <value>]
FLAGS
-d, --output-dir=<value> Path where package manifests will be created.
-f, --output-format=<option> Specify in which manifest file the content is written.
<options: PackageXML|DestructiveChangesXML>
-m, --metadata-type=<value>... Only include specific metadata types in the result.
-o, --target-org=<value> (required) Target org to analyse.
-p, --package=<value>... Only include metadata from specific packages.
-v, --devhub-org=<value> Used to resolve package ids when garbage must be filtered by package (--package).
--api-version=<value> Override the api version used for api requests made by this command
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Collect garbage on your org and export to json or package.xml for more actions.
Identifies left-overs from package upgrades. This includes deprecated components (custom fields, objects, layouts, etc
that were removed from package content, but not deleted on target org after install), outdated flow versions, empty
test suites, etc. The structured JSON output gives you insight into the metadata types still on the org and how they
can be processed. You can optionally generate a package.xml or destructiveChanges.xml for further processing.
EXAMPLES
$ sf jsc maintain garbage collect -o Production --json
$ sf jsc maintain garbage collect -o Production -d my-package-dir
$ sf jsc maintain garbage collect -o Production -m ExternalString -m CustomObject
$ sf jsc maintain garbage collect -o Production -m ExternalString -p SalesCRM -d tmp/test-run
FLAG DESCRIPTIONS
-d, --output-dir=<value> Path where package manifests will be created.
When provided, creates manifest file (package.xml) at the target location with all exported content. Use the
--output-format flag to write contents to destructiveChanges.xml.
-f, --output-format=PackageXML|DestructiveChangesXML Specify in which manifest file the content is written.
The default option prepares a package.xml with all exported components. If you specify DestructiveChangesXML, the
command creates an empty package.xml and writes all components into destructiveChanges.xml. This flag only has an
effect, if the output directory is set. No source is retrieved or deployed.
-m, --metadata-type=<value>... Only include specific metadata types in the result.
Only provided metadata types are processed and added to "deprecated components" result. All other will be ignored.
You can specify this flag multiple times. Use the developer name of the entity definition (e.g. ExternalString
instead of CustomLabel). Values are case insensitive.
-o, --target-org=<value> Target org to analyse.
The org that is queried for deprecated package members and outdated flow versions.
-p, --package=<value>... Only include metadata from specific packages.
You can specify the package id (0Ho) or a local package alias from your sfdx-project.json to narrow down package
members only from a specific package. You can specify this flag multiple times.
-v, --devhub-org=<value> Used to resolve package ids when garbage must be filtered by package (--package).
Package filters are set with the "0Ho"-Id of the Package2 container. The DevHub is needed to resolve these ids to
the canonical "033" Ids. If your target org is a devhub, it will automatically be used. This parameter is only
needed, if you specify at least one package flag.
See code: src/commands/jsc/maintain/garbage/collect.ts
Roll out a manifest. This deploys the artifacts of the manifest (unpackaged, package, etc) to the target org.
USAGE
$ sf jsc manifest rollout -m <value> -t <value> -o <value> [--json] [--flags-dir <value>] [--validate-only]
[--api-version <value>]
FLAGS
-m, --manifest=<value> (required) A manifest file that defines the desired state of the target org
-o, --devhub-org=<value> (required) Devhub that owns the packages. Needed to resolve package versions.
-t, --target-org=<value> (required) Target org (sandbox, production, etc) where artifacts of the manifest should be
rolled out.
--api-version=<value> Override the api version used for api requests made by this command
--validate-only Only validate the manifest file, do not perform any rollout actions like package installs
or source deploys.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Roll out a manifest. This deploys the artifacts of the manifest (unpackaged, package, etc) to the target org.
The command takes an Org Manifest and rolls out its artifacts to a target org. Dynamic paths for unpackaged artifacts
are resolved based on mapped environments, package versions are resolved based on the DevHub org.
EXAMPLES
$ sf jsc manifest rollout
See code: src/commands/jsc/manifest/rollout.ts
Validate a manifest file. Same result as running "rollout" with "--validate-only".
USAGE
$ sf jsc manifest validate -m <value> -t <value> -o <value> [--json] [--flags-dir <value>]
FLAGS
-m, --manifest=<value> (required) A manifest file that defines the desired state of the target org
-o, --devhub-org=<value> (required) Devhub that owns the packages. Needed to resolve package versions.
-t, --target-org=<value> (required) Target org (sandbox, production, etc) where artifacts of the manifest should be
rolled out.
GLOBAL FLAGS
--flags-dir=<value> Import flag values from a directory.
--json Format output as json.
DESCRIPTION
Validate a manifest file. Same result as running "rollout" with "--validate-only".
The manifest file is validated against a DevHub and Target Org. It tries to resolve package versions and deploy paths
for all artifacts, but does not attempt to rollout the artifacts to the target org.
All artifacts are returned as RESOLVED, if validation succeeds.
EXAMPLES
$ sf jsc manifest validate
See code: src/commands/jsc/manifest/validate.ts
To build the plugin locally, make sure to have yarn installed and run the following commands:
# Clone the repository
git clone git@github.com/j-schreiber/js-sf-cli-plugin
# Install the dependencies and compile
yarn && yarn buildTo use the local build, run using the local ./bin/dev or ./bin/dev.cmd file.
# Run using local run file.
./bin/dev.js hello worldThere should be no differences when running via the Salesforce CLI or using the local run file. However, it can be useful to link the plugin to do some additional testing or run your commands from anywhere on your machine.
# Link your plugin to the sf cli
sf plugins link .
# To verify
sf plugins