Skip to main content

Team Workflow

Daily flow​

A practical Salesforce trunk-based workflow looks like this:

  1. Pull latest main.
  2. Create a short-lived branch only if review workflow requires it.
  3. Develop in an isolated personal sandbox or even better, a scratch org.
  4. Keep the change small enough to merge within one to two days.
  5. Validate locally using the same commands CI will run.
  6. Open a pull request.
  7. Pass automated checks.
  8. Merge to main.
  9. Delete the branch.

Work sizing rules​

The workflow only works if the team sizes work correctly:

  • Split large stories into mergeable increments.
  • Break down changes so they can be delivered safely without breaking existing behavior.
  • Make the workflow durable. If it is not automated, it is not repeatable.
  • Deploy as early and as quickly as you can. Release when ready.
  • If a change will take longer, use feature flags, branch by abstraction, dark launches, or delayed connection patterns instead of extending branch lifetime.

Salesforce examples​

Good candidate for one short-lived branch​

  • Add an Apex service method.
  • Add a FlexiPage change that is permission-gated.
  • Add logs to an existing workflow.
  • Add tests.
  • Add a permission-controlled UI entry point.
  • Visibility changes controlled by public groups.

Bad candidate​

  • A multi-week branch containing object model changes, flows, Apex refactors, profile edits, and deployment fixes waiting for one release event.

That second example is exactly how teams recreate late integration and then act surprised by the fallout.

Pull request expectations​

Pull requests should be:

  • Small enough to review quickly.
  • Linked to one narrow outcome.
  • Backed by automated validation.
  • Safe to merge without waiting for a massive release window.

Release behavior​

Near a release, most developers should continue normal work on main. Releases should not be surprises. The code and configuration needed for the release should already exist in trunk behind the right rollout controls, and the rest of the team should not be dragged into a code freeze.

References​