OrgFlow

OrgFlow helps Salesforce configurators move named metadata from a sandbox to QA, UAT, or production. Work in order: Start → Package → Retrieve → Confirm. You cannot skip ahead. Log into both orgs in Chrome, detect them, and set From and To in the path bar (org names, not usernames). Package starts with what just changed in the From org; you can browse types when you need them. After you pick members on an object, OrgFlow can add a small set of matching layouts or record types in one tap. Back from Retrieve returns to Package unlocked so you can add members, then retrieve again. On Retrieve, a Jira key (PROJ-123) and comment are required. After retrieve you can compare this package (left) with a saved snapshot (right) on the same screen. Confirm shows what will go to the To org. If Apex is in the package, running tests is optional and does not add test classes to the package; coverage appears after Validate or Deploy when tests ran. Validate in To org is a dry run; Deploy sends it; the result stays on that screen. Versioning is always on. Snapshots are keyed by Jira (PROJ-123-v1). Keep them in this Chrome profile, or share them in GitHub, GitLab, or Azure DevOps so teammates can reuse the same package. With a team repo you can: - Save pipelines (From, To, test level) to .orgflow/pipelines.json - Save each retrieve as v1, v2, … with a required commit message, under .orgflow/releases with Salesforce metadata folders (classes, objects, layouts, lwc) - Detect an existing force-app / src / manifest project so OrgFlow never overwrites it - Compare a retrieve with a previous version before you deploy (metadata XML and Apex diffs) - Revert selected files into the current retrieve - Deploy a saved version to the next org OrgFlow talks to the Salesforce Metadata API using your existing browser session. No Connected App is required. Git tokens stay in this browser and are never written to the repo. Not a full Copado or Gearset replacement: no data (records) deploy, no dependency graph.