Start

Getting Started

Eat the elephant one bite at a time - choose a path, adopt the smallest useful tools, then reach for the larger frameworks.

Choose a Path

Install the unlocked package

Use this path when you want Bedrock available in a Salesforce org without cloning or deploying source yourself.

Clone the repository

Use this path when you want the source locally for review, customization, contribution, or source-driven deployment.

If you clone the repository, the implemented Apex library source lives in:

force-app/bedrock/lib

A fresh checkout starts with:

git clone https://github.com/force-creators/sf-bedrock.git

Start Small

You do not need to adopt the whole toolkit at once. Pick one service, one test, and one small seam. Most teams begin by routing service-layer reads and writes through Query and DML, then use TestData to build records without setup bloat.

The goal is boring production code

Bedrock should make the safe path easy. Your services should still read like normal Apex, and your tests should prove behavior without begging the database for help.

First Tools

TestData

Build in-memory records with mock Ids, parent relationships, and fields the normal constructor will not let you set.

DML

Replace raw writes with a tiny facade. Production commits. Tests capture inserts, updates, upserts, deletes, and undeletes.

Query

Keep SOQL in production and swap in test results without relying on org data, SeeAllData, or fragile setup.

Pluck

Turn record lists into deduped Id sets for list-driven services and framework APIs.

A note on Query

Apex evaluates method arguments before a framework method receives them. If you pass inline SOQL into Query.records(...), that query still runs first. Use Query as a seam around records your unit consumes; use a selector or service when query construction itself needs a stronger boundary.

Explore Frameworks

Once the small seams feel natural, reach for a framework when the platform problem itself needs structure. These tools are heavier because they own lifecycle, coordination, or operational behavior.

TriggerHandler Keep triggers thin and route context to the hook that owns the work.
RecordBuffer Stage related writes during a transaction, then flush grouped DML once.
Async Process record Ids in tracked background batches instead of burning Queueable slots.
EventRelay Publish and consume Platform Events as durable, tracked work.
Scheduler Run recurring jobs from metadata without consuming one scheduled Apex slot per logical job.
REST Route versioned Apex REST endpoints through focused, testable handlers.

Operations

The optional Bedrock Console lives here:

force-app/bedrock/console-app

It gives teams views for async backlog, errors, completed work, async job configuration, and scheduler status. It is there for debugging and recovery; the programming model still lives in the library contracts.

Read the short Bedrock Console page when you are ready to give admins and developers an operations window.

For source-driven adoption, deploy only the library source you use first, then add the console when your team wants Salesforce-facing visibility.