Innovative ways of handling and processing your Salesforce metadata that challenge conventional wisdom and enable new levels of simplicity and performance.
OrgFlow provides a powerful and flexible way to specify which subset of metadata you want to flow, using wildcards and glob patterns for namespaces, types and/or component names. Any metadata matching the rules you've specified in the
.orgflowinclude file in your Git repository, is automatically included in change detection, version control and flow between environments — anything else is ignored and untouched.
In OrgFlow, a deployment from Git to Salesforce doesn't have to be an all-or-nothing operation. If one or more components fail to deploy, the deployment can be continuously retried without those components, to eventually allow a best-effort partial deployment to succeed, or — in the case of a validation-only deployment — to provide you with the complete set of failures up front.
Having your full metadata change history in Git can show you the what and the when — but it gets even more powerful when it can also tell you the who. OrgFlow groups commits in Git per Salesforce user who last modified the changed metadata files, which means original author information from Salesforce is preserved in the your Git history.
Still using Excel to remember which components admins and developers have changed in a development sandbox? OrgFlow automatically detects which changes were made in a given Salesforce org since it was last synced with its Git branch — including components that have been deleted. No change forgotten — no change left behind.
If you have enabled source tracking, OrgFlow automatically and transparently utilizes source tracking data in each sandbox to improve accuracy of change detection and author attribution, dramatically improve performance of metadata retrieval, and detect and prevent potential clobber during deployment. For orgs and metadata which do not support source tracking, OrgFlow gracefully falls back to less performant techniques.
Deleted metadata components cannot be deployed using changesets — but they are fully supported in OrgFlow. Deletes are automatically and reliably propagated through all parts of the flow. You won't have to worry about hand-crafting the right elements into the right
destructive*.xml file anymore — with OrgFlow, it just works.
Some Salesforce metadata looks different each time you retrieve it, which has traditionally made it extremely challenging to effectively version control, branch and merge. OrgFlow makes all metadata deterministic by always normalizing things like formatting, indentation and element ordering before committing to Git. No more phantom changes or messy merge conflicts due to randomly re-ordered elements.
In OrgFlow, each sandbox is a Git branch, so customizations always flow through Git — never directly between Salesforce orgs. Which means the power of Git is applied in every step of the process. No change is forgotten, no change gets lost, no change gets overwritten, and conflicts are either automatically resolved or clearly surfaced for the operator to handle.
Retrieving metadata from a large Salesforce org can take a long time. In OrgFlow, metadata retrieval is split into smaller chunks that are retrieved concurrently and then reconstituted into the full archive, which significantly improves performance. It also works around the 10000 component limit imposed the metadata API, so you can flow metadata changes with no limits.
When flowing changes from Salesforce into Git, or between environments, OrgFlow 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.
Our smart normalization engine avoids "phantom" merge conflicts, but of course, legitimate conflicts do happen. When run interactively on your local computer, OrgFlow provides interactive conflict resolution during flow operations, allowing you to use your favorite graphical merge tool to resolve the conflicts and resume the flow.
Instead of relying on hard-coded support for different types of metadata, we have built OrgFlow so that its metadata handling is driven almost entirely by the metadata description provided by the Salesforce API. This means you don't have to wait for us to add support for new metadata types before you can start flowing them between your environments.
Having to manually install managed packages in all your orgs can be a pain. OrgFlow can automatically sync installed packages between environments. Additionally, even in metadata that belongs to managed packages, some things are customizable — such as object description texts. OrgFlow supports flowing such changes between your environments.
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