Jira Salesforce development workflow: how we manage 15 client orgs

Why a Jira Salesforce development workflow matters with several orgs

With one org, you can remember what changed. With 15, you cannot. A field added in the wrong org, a flow deployed before it was tested, or a fix nobody wrote down turns into a support ticket later.

So the workflow is the same in every org. How we set up the Jira board itself (columns, ticket fields, time tracking, client filters) is in our Jira for project management guide. This post is the Salesforce side.

1. Every change is a ticket in that org's project

• Each client org has its own Jira project, so a ticket can only be about one org.
• A request with ten items becomes ten tickets. A large ticket gets split into sub-tickets before work starts.
• The ticket names the objects, fields, flows or classes it touches, so the next person can find them.

2. Sandbox first

Before any build, we confirm access to the org and a sandbox. New work, from a field to a full integration, is built in the sandbox, away from live data and users.

• Bigger pieces start as a proof of concept in the sandbox, so the client sees it working before the full build.
• Integrations are tested against the other system's test or sandbox environment where it has one.
• We use AI agents (Claude) in development work. Their output goes through the same sandbox and QA as anyone else's.

3. QA, then client review

4. Deploy to production, then QA again

• Take a backup before a large deployment or data change.
• Deploy the sandbox changes to production as one tracked deployment, listed on the ticket.
• Run a round of QA in production with the same scenarios, then move the ticket to Done.
• Watch error emails from flows and Apex after the deploy.

5. Document what changed

The ticket is the history. The documentation is the map. For each org we keep field mapping documents for integrations and technical documentation of the automations, flows, Apex classes and business logic, and we update them when a ticket changes them.

Changes that touch all 15 orgs

Some work is the same everywhere. Salesforce retires old API versions, a shared integration changes, or we find a fix in one org that applies to others.

• Open a ticket in each affected org, not one shared ticket, so each org has its own history and QA.
• Check each org: code, flows and integrations on retired API versions are found and updated org by org.
• Set up the same safeguards in each org: backups, error alerts and documentation.

This is how we run Salesforce managed services. If your org has no process behind its changes, book a free call.