Flow In metadata. Retrieve metadata for a particular Environment from your Salesforce organization and commit it to your Git repository.
The name of the stack to target. Stack names are case-insensitive. Stacks are specific to license keys, and you can see a list of all available stacks with the stack:list command.
This value is required if no valid default stack has been set, or if you would like to target a stack other than the one that is currently the default stack. You can use the stack:setdefault command to set or change the default stack.
Required. Prompted for when not specified, and possible to do so.
The name of the environment to flow in. Environment names are not case-sensitive.
The key used to encrypt or decrypt stored credentials.
- You want the process to utilise previously encrypted credentials, or if you want the process to save credentials
- AND the encryption key has not been saved locally with the auth:key:save command, or the key that has been saved locally is not the key that you wish to use
Required. Prompted for when not specified, and possible to do so. If a blank value is specified, then the OrgFlow CLI will construct a default message to use.
The message to be used when committing changes to the Git repository. The flow in process may create more than one commit, and the same message will be used for all commits.
If specified, a validation-only inbound flow is performed, which means no changes will be pushed to your configured remote Git repository, and no changes will be persisted in the Environment State. This is useful to proactively detect potential merge conflicts, collect information about which changes would be applied to your environment were it to be flowed in, or to check if any changes have been made to an org that you wouldn't expect changes to be made (such as your production org).
Specifies how unresolved merge conflicts encountered during inbound flow should be handled.
prompt: Prompt user interactively for each encountered set of unresolved merge conflicts if possible, otherwise abort the inbound flow
allAsLocal: Resolve all merge conflicts by letting the version in the Git branch win
allAsRemote: Resolve all merge conflicts by letting the incoming version from the Salesforce org win
askForEach: Let user choose between local and remote for each conflicted file
gitMergetool: Run configured
git-mergetoolcommand for each encountered set of unresolved merge conflicts
abort: Abort the inbound flow if any unresolved merge conflicts are encountered
The specified conflict resolution strategy applies only to files which could not automatically resolved by Git. If not specified, the default behavior is equal to
Specifies how metadata is retrieved from the Salesforce org. The default value is
auto: Favor a Partial Retrieve if it is safe and possible to do so, fall back to a full retrieve if not
partial: Never fall back to a full retrieve, always do a partial retrieve (even if it is not safe to do so); fail if it is not possible to do a partial retrieve (e.g. if source tracking is not enabled in the org)
full: Always do a full retrieve, even if a partial retrieve would be possible
If specified, the metadata that is retrieved from the Salesforce organization is committed to the Git repository as-is. The OrgFlow CLI will make no attempt to merge the changes in the Salesforce organization with the changes in Git (if any).
The end result is that the metadata in the Git repository will match the metadata in the Salesforce organization, but any change to the metadata that is in Git but not in the Salesforce organization will be lost.
This has the side effect of removing all Undeployable Components from the state store for this specific environment.
If specified, the OrgFlow CLI will retain the zip files containing the metadata items that are retrieved from Salesforce. The zip files will be placed into the directory specified. This can be useful in scenarios where you need to troubleshoot problems.
The maximum amount of time to wait (in minutes) for environments currently locked by other users or OrgFlow instances to be released. Default is
0(i.e. do not wait but rather fail this command immediately).
Any command that mutates the state of an environment in any way always acquires an exclusive lock on that environment, to prevent other instances from trying to mutate the same environment simultaneously - something that could have unpredictable results. Particularly in scripted or CI/CD scenarios, it can be useful to have OrgFlow wait a certain amount of time for an already locked environment to become available, rather than failing immediately and requiring the script to be executed again.
The following options are global across all commands:
If specified, prints help for this command instead of executing it.
The License Key you were issued to allow you to use the OrgFlow CLI. If a valid key is supplied, it is stored locally on the machine so that it does not need to be specified again on the next execution.
If specified, you are signifying that you accept our End User License Agreement (EULA). You only need to specify this once per device, because your acceptance will be cached on the device (you can pass
--acceptEula=falseif you wish to clear this). You must accept our EULA to be able to run most OrgFlow commands.
If specified, a log file is written to the specified path. The specified path may contain one or more tokens; see Logging for more information.
The minimum log level to be written to the log file; logs below this level will not be written. Only effective if a valid value for
--logTohas been specified.
If the CLI encounters an exception then it will ask (where possible) the user whether or not to create a Diagnostic Bundle and write it to disk. If it is not able to prompt then no action is taken. This is the default behaviour (
You can change this default behaviour (and suppress the prompt) by specifying either
Never(which will always write the bundle or never write the bundle, respectively). This is particularly useful in a CI/CD context, where the CLI may not be able to prompt, but you still want to create diagnostic bundles for all failures.
If specified, sets the location to write the Diagnostic Bundle (if any). If not specified, a default location will automatically be chosen. This default location depends on a number of factors, including the operating system and some file-system based restrictions that might be in place. The location that the diagnostic bundle is ultimately written to is always included in the standard error output of the CLI.
If specified, suppresses confirmation prompts that the CLI might raise before performing destructive or dangerous procedures. If suppressed, the CLI assumes that the prompts would have been answered positively and continues with execution.
Controls how progress is printed to the standard error stream:
Interactive: Progress is sent to the standard error stream only if the standard error stream is connected to an interactive terminal.
Never: Progress is not sent to the standard error stream.
Always: Progress is sent to the standard error stream, even if that stream has been redirected.
If specified, sets the location to use as storage for files that may need to be stored on disk temporarily during command execution. For example, the location on disk where zip files containing metadata from Salesforce are downloaded to before they are unzipped.
If not specified, the CLI will automatically choose an appropriate location on disk (usually in the current user's temporary storage location). This automatically chosen location may be deeply nested within a drive, which may be problematic if the operating system imposes limits on file path lengths and the files placed into temporary storage have particularly long paths or names.
Switches the format of the output sent to the standard output stream to JSON. This is the most verbose output available, and is useful for scripting or automation.
If specified, the CLI will ignore any cached Salesforce access tokens, and will require the Salesforce authentication process to be re-completed for each organisation that the command connects to.
If no value is specified, the CLI will indefinitely retry any process that fails due to a transient error. This is the default behaviour, and allows for resilience against temporary issues that might otherwise cause a process to fail.
Specify a positive integer value to prevent indefinite retries. Each process that fails due to a transient error will be retried up to a maximum amount of times specified. For example,
--maxTransientErrorRetries=5: Each process that fails will be re-tried up to a maximum of five times. If an earlier process fails four times but then succeeds on the fifth attempt, the counter is reset for the next process.
--maxTransientErrorRetries=0to disable transient failure retries.
Processes retried due to a transient error are delayed by a back-off policy that gradually increases the time to wait between retries. Specify a non-negative integer value as the maximum amount of seconds to wait between attempts.
--maxTransientErrorDelay=0to disable the back-off policy and always instantly retry failed processes.
Interactively flow an environment in:
Flow an environment called
UAT in, with a custom commit message:
orgflow env:flowin --environment=uat --message="Adds new Account layout"