Serpent is a DevOps platform for Salesforce teams. It gives every change a tracked, reviewable home so you can build, review, and release without hand-managing Git branches, orgs, and deployments. This page explains the core objects, flags which terms are standard Salesforce and which are specific to Serpent, and sets out what to expect at each step.
The core objects
Workspace
A Serpent term. Your team's top-level container: it holds your projects, members, orgs, and billing. Most teams have one workspace.
Project
A Serpent term. One delivery pipeline: its own repository, connected orgs, review policy, and team. You create Work Items inside a project, and its settings decide how changes are reviewed and shipped.
Work Item
A Serpent term, and the one to know first. A Work Item is the unit of change: one feature or fix, with its Git branch and tracked scope set up for you. Think of it as a ticket and its branch combined, so you work on the Salesforce changes instead of managing branches by hand.
Orgs, sandboxes, and production
Standard Salesforce terms. An org is a Salesforce environment. Sandboxes are copies for building and testing; production is the live org your users work in. A project connects the orgs it develops against and releases to.
Dev Hub and scratch orgs
Standard Salesforce terms. A scratch org is a temporary, source-driven environment created on demand for a single piece of work, then discarded. A Dev Hub is the org that authorizes creating them.
Review request
Serpent's name for a pull request. When a Work Item is ready, it goes through a review request so a teammate can approve the changes before they are deployed. Whether review is required is set per project.
Automation flow
A Serpent term. A configurable pipeline that runs steps automatically, such as deploying on merge or back-promoting a change, so routine delivery work does not have to be done by hand.
Release
A batch of changes deployed together and tracked as one unit, so you can see what shipped and roll back if needed.
How the pieces fit together
The workflow runs top to bottom: a workspace holds your projects; inside a project you create a Work Item for each change; you build the change against your orgs; you send it through a review request; and approved work ships in a release. A Work Item maps to a branch, a review request maps to a pull request, and a release maps to a deployment.
What to expect when you create a Work Item
When you create a Work Item, Serpent creates its Git branch immediately and opens the Work Item ready for your changes. This depends on the project's source control already being connected. If no branch appears, source control is not connected yet: open Project Settings > Source Control, connect your provider, then create the Work Item again.
When to use Serpent
Reach for Serpent when you want Salesforce changes tracked, reviewed, and released the way a software team ships code, but without wiring up branches, scratch orgs, and deployment scripts yourself. It replaces the manual routine of change sets, hand-managed branches, and one-off CLI deploys with a guided, reviewable path from work item to production.