All the functionality you need to build, manage, automate and operate a full end‑to‑end Salesforce DevOps process.
The env:create
command automates the creation of new environments — including sandbox creation and branch creation — in a single easy-to-use command that can be started once and left to run unattended.
Mutations made by the platform during sandbox creation are automatically reverted with an initialization deployment as soon as sandbox is ready, to ensure environments are truly identical.
Similarly, the env:delete
command automates the deletion of an environment and its resources, while the env:list
command provides an overview of all your environments together with useful details about each environment's Salesforce org.
The env:tags:set
and env:tags:delete
commands enable you to manage tags on your environments. Tags can be used as input in your scripts and CI/CD pipelines to make them more dynamic, and they can also help keep your environments organized.
The flow:in
command automates the entire process of detecting changes in Salesforce, retrieving the metadata, normalizing it for seamless version control, detecting and resolving conflicts, and committing the changes to the appropriate Git branch — all in a single easy-to-use command.
Formatting and element ordering is normalized before commit, using smart and customizable metadata normalization rules, to help reduce insignificant changes and "phantom" conflicts when merging metadata.
OrgFlow can help improve accountability within your team by adding author information from Salesforce into your Git commit signatures, so you can trace changes in your Git history to the actual Salesforce users that made them.
OrgFlow automatically detects which changes were made in the Salesforce org since it was last synced with its Git branch — including components that have been deleted. No change forgotten — no change left behind.
For sandboxes where source tracking is enabled, OrgFlow utilizes it to determine which metadata has changed since last inbound flow. This dramatically increases performance and accuracy of change detection and author attribution.
OrgFlow intelligently combines incoming changes with any undeployed changes whenever the Git branch is ahead, which means metadata changes from multiple sources can be merged together instead of overwriting each other.
Metadata is split into smaller chunks and retrieved in parallel for unparalleled speed. Large orgs with hundreds of thousands of metadata components are handled with the same simplicity as smaller orgs.
The flow:out
command automates the entire process of figuring out which changes in Git have not yet been deployed, creating a delta deployment archive with the changes, generating the necessary package manifests, and deploying it all to Salesforce in a continuous exclude-and-retry loop — all in a single easy-to-use command.
You have fine-grained control over which Apex tests are run during deployment — or you can simply rely on the automatic test behavior of the target org type. Test results can be exported in JUnit format for in-depth reporting and analysis.
Git history diffing is used by default to determine undeployed changes at per-component level, removing the need to retrieve metadata from Salesforce and minimizing clobber of unrelated metadata that may have been changed in your org. Full org diff is also supported as an option.
If enabled in Salesforce, source tracking data is utilized automatically to detect and show any uncommitted changes in your sandbox that would be clobbered by the deployment, letting you choose whether to abort or continue the deployment.
OrgFlow supports best-effort partial deployments — even to your production org. Our unique continuous deployment engine keeps track of undeployable components and excludes them from subsequent attempts.
A --checkOnly
option runs validation deployment in a continuous exclude-and-retry loop until there are no more failed components, to show you the complete set of failures up front without altering the target org.
OrgFlow also provides powerful all-in-one operation to flow changes from a source org, via Git branches, all the way to a target org. Essentially an all-in-one deployment tool, the flow:merge
command automates the entire process — including inbound flows of both environments, Git merge between the branches, interactive conflict resolution, and outbound flow of the target environment — in a single atomic operation.
OrgFlow's innovative eventual consistency based approach using partial deployments and undeployable component tracking, enables a simpler and more automatic self-healing deployment process that makes Salesforce DevOps easier, faster and safer.
The merge flow uses clever algorithms to always rely on Git merge — never on copy-paste semantics — so that no changes can ever be accidentally lost or overwritten, even if a Git branch contains undeployable components, or contains changes that have not yet been deployed to its org.
Using the --checkOnly
option lets you run an orchestrated atomic validation merge flow, for early up-front discovery of any merge conflicts, deployment failures and test failures — without persisting any changes to either Git or Salesforce.
The env:test
command provides a convenient way to run Apex tests in your Salesforce environments, either manually on demand, or based on schedules or triggers in your CI/CD platform.
Create a script or take advantage of the scheduling features of a CI/CD platform to run Apex tests on a frequent basis. Discovering test failures early makes it easier to identify the change that caused them.
Avoid blocked deployments by knowing in advance which tests will fail. Run all Apex tests in your development sandboxes frequently, to weed out any failing tests and fix them before they block your next deployment.
Run Apex tests from your CI/CD platform and publish the test results for analysis. Exporting Apex test results in standardized JUnit file format opens up a new level of reporting capabilities.
Take advantage of advanced reporting in your CI/CD platform to pinpoint the change that caused a test to begin failing, create work items straight from a failing test, or to associate a change as a root cause of a failing test.
Some teams require more than one stack, and OrgFlow provides stack:create
, stack:delete
and stack:list
commands, allowing you to effortlessly create and manage multiple stacks in your OrgFlow account.
The first command you will run when you get started with OrgFlow is the stack:create
command, which automates the initial setup of your stack — including connecting to your Salesforce environment, configuring your Git repository, and syncing your production environment with your main
branch for the first time — with a single easy-to-use command. The stack:setdefault
command saves you the trouble of specifying a target stack every time.
By default, OrgFlow interacts with Salesforce and Git on your behalf using credential-less techniques like browser-based sign-in or pre-configured SSH keys. But it can also securely store credentials, allowing it to work seamlessly in scenarios where interactive sign-in is not an option.
The auth:key:create
and auth:key:save
commands enable you to create and store encryption keys on your local computer, and the auth:salesforce:save
and auth:git:save
commands let you use those encryption keys to store encrypted credentials for different scopes of both Salesforce and your Git repository.
Encrypted credentials can be stored locally on the device where OrgFlow is running, or you can store them securely in our cloud-based state store so they can be shared and reused between different operators and devices.
Don't take our word for it — see for yourself! Try OrgFlow free for 2 months. No limits. No strings attached. No credit card or billing information required.
Try Now