Learn Salesforce Administration: A Free, Hands-On Admin Course

If you want to learn Salesforce administration, start with the data model, security and reporting, then learn Flow for automation. That's exactly the order I teach it in. Salesforce Administration Training is completely free, and every episode is built live in a real org: I create the objects, write the formulas, break the validation rules and fix them on camera.

The syllabus for both courses is above. Below is what administration actually involves on a real project, what you need before you start, and the mistakes I see new admins make again and again.

What a Salesforce admin actually does on a project

An admin turns business requirements into a working org without writing code. On a typical implementation, that means:

• Designing the data model. Which objects you need, whether a relationship should be a lookup or a master-detail, and which fields belong where.
• Shaping the user experience. Page layouts, Lightning record pages, list views, search layouts, record types and dependent picklists so each team only sees what it needs.
• Protecting data quality. Formula fields, validation rules and required fields that stop bad data before it lands.
• Controlling access. Org-wide defaults, the role hierarchy, sharing rules, profiles and permission sets.
• Answering questions with data. Reports, report types and dashboards that managers actually use.
• Automating processes. Today that means Flow. Salesforce has retired Workflow Rules and Process Builder for new automation, so everything new belongs in Flow.

None of this is glamorous, and all of it matters. A clean data model and a well-understood sharing model make every later piece of work, including Apex and LWC, easier.

Prerequisites

You need less than you think:

• A free Developer Edition org. Sign up for one and keep it just for practice.
• Familiarity with how a business works: leads, accounts, opportunities, cases. If you've used a CRM as a user, you're ahead.
• Comfort with spreadsheet-style formulas. Salesforce formulas will feel familiar.

You don't need to know any programming language. If you later move into development, the admin-to-developer roadmap picks up where this leaves off.

What you'll be able to build afterwards

By the end of the admin course and the Flow course, you should be able to take a requirement such as "track equipment loans to customers" and deliver it end to end:

• A custom object with the right relationship to Account, plus record types for different loan categories
• Validation rules that enforce return dates and block impossible values
• A sharing model where reps see their own loans and managers see their team's
• A report and dashboard showing overdue loans by region
• A record-triggered flow that notifies the owner when a loan becomes overdue

That's the shape of most real admin work: one business process, delivered across data, security, reporting and automation.

A hands-on example: a validation rule that fails properly

Here's the kind of thing I build in the course. Sales leadership wants a reason captured every time a deal is lost. The obvious fix is to make the field required on the layout, but then reps can't save an open opportunity without it. A validation rule enforces it only when it matters:

AND(
  ISPICKVAL(StageName, "Closed Lost"),
  ISBLANK(TEXT(Loss_Reason__c))
)

The rule fires (and blocks the save) when the formula returns true: the stage is Closed Lost and the loss reason is empty. A few details are worth noticing:

• ISPICKVAL is how you compare a picklist. You can't use = on a picklist field directly.
• ISBLANK(TEXT(...)) handles the picklist-to-text conversion, because ISBLANK doesn't accept a picklist on its own.
• You'd attach the error message to the Loss Reason field so the user sees it right where they need to act.

Then I break it on purpose: what happens when a data loader update or an integration closes 500 opportunities without a loss reason? The rule blocks those too. That conversation about who else writes to this object is the real lesson, and it's why I build things live instead of showing a slide.

Common mistakes beginners make

These come up in almost every org I've reviewed:

1. Opening access with the org-wide default, then trying to lock it down. Sharing rules can only grant access, never remove it. Set the most restrictive org-wide default you need, then open up with the role hierarchy, sharing rules and permission sets.
2. Granting everything through profiles. Keep profiles lean and give access with permission sets and permission set groups. It's far easier to audit and change.
3. Using record types where a picklist would do. Record types are for different page layouts, picklist values or business processes. If all you need is a category, use a field.
4. Hard-coding IDs in formulas and flows. IDs differ between sandboxes and production. Use custom metadata, custom labels or developer names instead.
5. Validation rules with no thought for integrations. Every rule also applies to data loads, APIs and Apex. Know who else writes to the object before you add one.
6. Building reports on the wrong report type. If records are missing from a report, check whether the report type requires related records ("with" versus "with or without").
7. Learning the old automation tools first. Read Workflow Rules and Process Builder so you can migrate them, but build every new automation in Flow.

How administration connects to everything else

Administration is the foundation of the whole Salesforce stack, so it connects to almost every other topic:

• Flow is the natural next step. Start with Salesforce Flows once you're comfortable with the data model and security.
• Apex builds on the data model and sharing you learn here. When you're ready, read the Apex topic guide and the admin-to-developer roadmap.
• CPQ is admin-heavy configuration on top of a managed package. If quoting interests you, look at Salesforce CPQ.
• The full career path is laid out in the Salesforce admin roadmap, and Flow interview prep lives in Salesforce Flow interview questions.

Who should skip this

Be honest with yourself here:

• Skip it if you already administer an org day to day and can explain your org's sharing model, record types and report types without looking them up. Go straight to Flows.
• Skip it if your only goal is passing the certification exam next week. This course teaches you to build. For exam drilling, use Trailhead and practice tests.
• Don't skip it if you're a developer who "never really learned the admin side". That gap shows up in code reviews and interviews alike.

Because the course is free, the cost of trying it is just your time. Watch a few episodes; if the way I teach works for you, the rest of the catalogue is taught the same way.