Describe the five core responsibilities of a Salesforce admin and the skills behind them
Manage users through their lifecycle: create, observe, support, freeze, and deactivate
Explain data management operations: backup, export, import, cleansing, sandboxes, and the data dictionary
Describe how Salesforce's three-per-year release cycle works and how organizations prepare for it
Run a feature selection and prioritization process with clear roles
Explain how BA skills transfer directly into admin work, and where the two roles hand off
Section 1
The Bridge Module
BA-to-Admin bridge
This is the course's explicit BA-to-Admin bridge. Module 1 drew the line between the two roles: BAs are project-based, admins are operational. This module walks you across that line. Everything here is what a working admin actually does all day, and it is written for two kinds of students: BAs who want to collaborate brilliantly with admins (every BA, in other words), and students aiming at admin or hybrid roles, which are among the most common first jobs in the ecosystem.
A Salesforce admin builds and manages trusted solutions on…
A Salesforce admin builds and manages trusted solutions on the platform: configuring, automating, and optimizing Salesforce to ensure org health and maximize return on investment. The successful admin blends technical and non-technical skills: communication, problem solving, security management, data analysis, a designer's mindset (human-centered experiences), process automation, and project management. Notice how much of that list you already recognize from the BA skill set. That overlap is the bridge.
One framing before the details, straight from Salesforce's admin…
One framing before the details, straight from Salesforce's admin research: build your practice on best practices, not tips and tricks. Quick hacks solve one problem once. Best practices are proven, repeatable strategies that apply across situations, like looking both ways before crossing the street: universal, portable, durable. Everything below is organized around that idea, grouped under the five core responsibilities of a Salesforce admin:
User management
Data management
Security
Product management
Actionable analytics
Section 2
Core Responsibility 1: User Management
User management involves configuring access, measuring adoption, and observing and communicating with users. Even a short period without proper access severely dents someone's productivity, so this responsibility is where admins most directly touch everyone else's working day.
The User Account
A user is anyone who logs in to Salesforce: employees (sales reps, managers, IT specialists) and also external users like customers and partners who access Experience Cloud sites. Every user has an account containing at least: username, email address, last name, alias, nickname, license, and profile (role is optional).
Key terms worth locking in:
Username: must be formatted like an email address and be unique across all of Salesforce, not just your org. It can match the user's email, but does not have to.
License: determines which features the user can access. A full Salesforce license unlocks standard features; lighter licenses grant narrower access. Licenses are what the organization actually pays for, which is why license questions surface in almost every project's scoping conversations.
Profile: defines default settings. As Module 7 established, modern practice assigns a minimum-access profile and grants capability through permission sets and permission set groups. The division of labor: permission sets carry user, object, and field permissions, custom permissions, and access to code and pages; profiles carry defaults like record types, assigned apps, page layout assignments, login hours, and login IP ranges.
Role: optional, one per user, and determines record visibility through the role hierarchy (again, Module 7).
The User Lifecycle
Adding users takes minutes: name, email, unique username, license, profile; Salesforce auto-generates a password and notifies the user. You can add up to ten at once through the standard interface.
Freezing a user instantly blocks login without freeing the license: the tool for urgent situations (a sudden departure, a suspected compromise) while you sort out what the account still owns, like queued notifications or scheduled jobs.
Deactivating a user removes all access and frees the license for reuse. Users are never deleted: their history, record ownership, and audit trail must survive them. Deactivated users lose access to everything, including records shared with them individually or as team members.
The rhythm to internalize: freeze now if it is urgent, deactivate properly soon after, never wait. Dormant accounts are unlocked doors.
The Habit That Makes Great Admins: User Observation
Here is the practice that separates adequate admins from beloved ones, and it should look extremely familiar after Module 3: regularly meet with and observe your users doing their actual work.
The mechanics: identify at least one person in each persona or profile. Schedule short sessions (fifteen minutes with a screen share and a virtual coffee is plenty). Watch how they work. Ask questions like: How would you normally accomplish this task? Which reports do you still export to a spreadsheet? What other departments do you interact with? Which part of this process is hardest? Rotate through groups and roles over time so every user experience is represented.
The discipline during these conversations: stick to business processes and value. Avoid Salesforce jargon, and do not ask users how they would solve it on the platform. You are hunting for friction, not collecting feature requests. Notice small things: service teams entering data in a different order than sales teams, a picklist nobody uses, a field everyone skips. Small friction, fixed, compounds into adoption.
Document every session, even the ones that reveal nothing new, and summarize findings for stakeholders. Some admins build a small "user feedback" app right in Salesforce to store observations: the tool managing feedback about itself.
If you have been paying attention across this course, you recognize this as requirements elicitation with a different name. A BA who becomes an admin arrives with this habit pre-installed. That is the bridge working in your favor.
Communication, Adoption, and the User Guide
The rest of user management is communication. Report on adoption (who logs in, who uses which features) and treat declining usage as a signal, not a nuisance. Communicate changes before they land (much more in Modules 13 and 15). And maintain a user guide: living documentation of how your org's processes work, kept current as things change. Admins inherit orgs with no documentation constantly; the ones who leave documentation behind are remembered kindly.
Section 3
Core Responsibility 2: Data Management
Data is only as valuable as its quality. Incomplete or outdated records discourage users, push them back to spreadsheets, and erode trust in the org. And in the AI era the stakes have risen: AI assistants and agents rely on org data to automate tasks and answer questions, so bad data (duplicate, inaccurate, incomplete, stale) directly produces unreliable AI output. Clean data has become an AI prerequisite, exactly as Module 2 previewed.
Backup: Because Everything Fails Sometime
Data loss happens for three main reasons, in descending order of likelihood:
User error: the overwhelming leader. Mass-import mistakes, incorrect automation or integration deployments, accidental overwrites and deletions, by users and by admins.
Sandbox refreshes: refreshing a sandbox copies production over it, which can wipe out weeks of work sitting in that sandbox.
Rare platform downtime: infrequent, but never impossible.
A backup strategy addresses both data (the records) and metadata (the configuration: fields, flows, layouts). Native tools cover the basics: the Data Export Service, Data Loader, and report exports for data; change sets, sandbox copies, and DevOps Center for metadata. Salesforce also offers a paid Backup & Recover product with continuous protection and field-level, point-in-time restore, and a healthy market of third-party backup and DevOps vendors exists. (Consistent with this course's policy: evaluate current vendor options fresh when you need them; any list printed here would be stale within a year.)
The admin habit: verify backups exist, run on schedule, and can actually be restored. An untested backup is a hope, not a plan.
Getting Data Out: Export
Two native export paths, and choosing between them is a classic admin decision:
Data Export Service: in-browser, from Setup. Manual export every 7 days (weekly-capable editions) or 29 days, or scheduled automatic weekly/monthly exports. Output is a zip archive of CSV (comma-separated values) files, emailed when ready. Options include encoding, including attachments and documents, and replacing line breaks with spaces for cleaner downstream processing.
Data Loader: an installable client application, operable through a user interface or command line. Command-line operation enables scheduled, automated exports and API-based integration with other systems.
Getting Data In: Import
The mirror-image decision, with real consequences for projects (data migration appears in nearly every implementation):
Data Import Wizard: built into Setup. Handles common standard objects (contacts, leads, accounts) and custom objects, up to 50,000 records at a time, with a friendly interface for field mapping (matching your file's column names to Salesforce fields). Choose it when volumes are modest, the object is supported, and no automation is needed.
Data Loader: up to 150 million records, any object, from files or a database connection, automatable via command line and configuration files. It processes through the SOAP API by default but can use the Bulk API, which is optimized for very large volumes through parallel processing and fewer network round trips. Beyond 150 million records, engage a partner.
Before any import, prepare the data: clean it in the source, deduplicate, standardize picklist values, and test with a small batch first. Import mistakes are the top cause of data loss (see above), and they arrive in bulk.
Cleansing, Sandboxes, and the Data Dictionary
Three ongoing hygiene practices round out data management:
Data cleansing: scheduled work (not "when we get to it") to find and fix duplicates, incomplete records, and stale values. Users notice clean data; they notice dirty data faster.
Sandbox refresh cadence: sandboxes are copies of production used for building and testing. They drift out of date; refresh them on a deliberate schedule, coordinated so nobody's in-progress work is destroyed (remember data-loss cause number two).
The data dictionary: documentation of every object and field: what it means, who uses it, where it came from. Essential for integrations, onboarding, and IT collaboration, and the direct descendant of the BA documentation discipline from Module 4. Share it with IT; keep it current.
Section 4
Core Responsibility 3: Security
Module 7 covered security in full depth, so here it is placed in its operational context: security is one of the five daily admin responsibilities, not a one-time setup task. The operational rhythm: apply least privilege through the permission-set-led model, review access when roles change, deactivate departures immediately, watch login history and Health Check, and coordinate continuously with IT on compliance standards, onboarding/offboarding processes, and integration security. Regular, proactive communication with IT (at whatever meeting cadence suits the organization's pace of change) is itself a security best practice: gather requests through the week, bring them consolidated, and keep the partnership strong.
Section 5
Core Responsibility 4: Product Management
Here is the mindset shift that elevates admins: manage Salesforce as a product within your organization, not just a system to maintain. Product management means ensuring Salesforce delivers maximum value and ROI, which involves strategic planning, understanding business needs, solution design, staying current with releases, governance, and continuous improvement.
The components:
Strategic planning and vision: define which business objectives Salesforce serves and communicate that vision to stakeholders.
Understanding business needs: act as liaison between the business and the platform, translating requirements into solutions. (Sound familiar? This is the BA role, embedded in the admin's chair.)
Solution design: choose wisely between standard and custom functionality, weighing scalability, maintainability, and user experience.
Governance and best practices: define design standards, deployment processes, and access controls. Larger organizations formalize this as a Center of Excellence (CoE): a cross-functional group of key stakeholders who set standards and make platform decisions together. Tools like Salesforce Optimizer and org health checks provide guidance on technical debt and unused features.
Continuous improvement: gather feedback, analyze usage, and proactively propose enhancements.
The Release Cycle
Salesforce delivers three major releases per year (Spring, Summer, and Winter), pushed to every org on the platform. Features arrive in three flavors: enabled automatically for users, available but requiring admin activation, and available for purchase as add-ons. This cadence is a gift and an obligation: new features arrive free with the subscription, but somebody has to notice them, evaluate them, and roll them out. That somebody is the admin, and organizations that skip this work accumulate feature debt: a growing shelf of unadopted innovations their competitors are already using.
Release readiness resources (start planning a couple of months before each release hits production):
Pre-release orgs: free preview orgs available three to four weeks before the sandbox preview: the earliest look at new features, without your customizations.
Sandbox preview: your own sandbox, upgraded to the new release early, so you can test your actual configuration against the incoming version.
Release notes: the definitive feature list, with filters that speed the hunt. A high-yield first pass: filter by feature impact for "enabled for users" (things your users will see with no action from you: know these cold before your users ask) and "admin must enable" (the opt-in treasure).
Community resources: a release readiness community, release overview decks, demo videos, and per-release learning modules. Other admins' "favorite feature" chatter is a legitimately efficient discovery mechanism.
Focus your testing where risk actually lives: features that change the user interface, and any custom code. Salesforce runs extensive regression testing on the platform itself, so standard functionality generally "just works"; your customizations are your responsibility. Use the sandbox preview for this, and if the org has meaningful custom code, involve developer expertise and automated tests. (Module 12 covers testing discipline in full; the release-testing types are the same: unit, integration, functional, UAT, performance.)
Selecting and Prioritizing Features
How do you decide which new features matter? Scale the process to the organization:
Simple orgs (a few dozen users, a handful of use cases): track user needs in a spreadsheet, focus on auto-enabled and few-click features, and communicate through a short email or video: what is changing, what is in it for the users, and anything that moves on their screens.
Complex orgs (many users, multiple teams, custom code): apply three principles, illustrated by a worked example from the source material featuring Barry, the admin at Abacus, a children's book company that grew from a few dozen Sales Cloud users to hundreds across sales and service:
Forward plan. Barry starts a couple of months before each release: contacting IT about technical resources and the sales and service managers about priority needs. He even shifts a team-onboarding project by a month so new users train on the new version rather than learning two interfaces in a season.
Define roles, responsibilities, and processes. Three key roles (one person can wear several hats):
Product owner / business subject matter expert: deep knowledge of a business function; leads gathering and prioritizing business requirements (at Abacus: the sales and service managers)
Salesforce subject matter expert: deep platform knowledge; educates the team on what the platform can do (Barry)
Technical expert: evaluates implementation effort, owns integrations and custom code implications (a developer from IT)
Raise your game with advanced tools. Beyond the spreadsheet: the community's per-release Release Matrix to analyze release contents systematically, and, delightfully, a custom Release Management app built in Salesforce itself: objects tracking each feature under evaluation, its business value, decision status, and owner. Managing Salesforce with Salesforce: reports and dashboards over your own release pipeline.
Read those three roles again with your BA hat on: "leads gathering and prioritizing of business requirements" is the product owner role, and in many organizations the person playing it comes from exactly the BA background this course teaches. Release management is a recurring, miniature version of the full project lifecycle: discovery (what do users need), analysis (which features fit), testing, training, deployment. If you can run a project, you can run a release.
Section 6
Core Responsibility 5: Actionable Analytics
Businesses aim to influence results; leaders rely on data to guide decisions; nearly every business action generates data. The admin's analytics responsibility is making that data actionable: aggregated, analyzed, and delivered where decisions happen. Imagine a support call center: satisfaction scores, call durations, case volumes per agent, escalations, refunds: analyzed well, these tell you where to invest effort.
The operational practices:
Attend quarterly business reviews (QBRs): meetings where leaders and contributors assess progress against goals. The admin does not run these; ask to observe. Note every moment Salesforce is used, praised, or blamed. Check in with stakeholders during breaks. Note new initiatives and dates, and prepare follow-up questions. A few hours per quarter buys a full map of what the business actually cares about.
Confirm and update KPIs (key performance indicators): after each QBR, compare your notes against current reports and dashboards. Metrics drift; last year's KPI may be this year's noise. Meet with stakeholders one-on-one to confirm what still matters.
Review and refresh key reports and dashboards: retire the unused, update the stale, and communicate changes. (Module 9 teaches the mechanics.)
Analytics tooling now spans from core platform reports and dashboards to richer tools (Tableau and unified data platforms among them), increasingly with AI assistance. The best practices above are deliberately tool-agnostic: they represent a way of working, not a product.
One more strategic lens from the source material, worth carrying forward: management thinker Peter Drucker's Five Most Important Questions (What is our purpose? Who is our customer? What does the customer value? What are our results? What is our plan?) map remarkably well onto admin work: KPIs aligned to mission, customer data revealing who customers actually are, dashboards tracking results, and the org roadmap serving the plan. Module 15 gives Drucker's framework full treatment; notice here simply that a platform admin sits closer to those five answers than almost anyone in the building.
Section 7
Crossing the Bridge: From BA to Admin and Back
Line the two roles up and watch the skills transfer:
BA discipline (Modules 1-5)
Admin operation (this module)
Requirements elicitation and stakeholder interviews
User observation sessions
Documentation: BRD, user stories, RTM
Data dictionary, user guide
Process mapping and gap analysis
Continuous improvement, Optimizer findings
Scope and change management
Release planning and feature prioritization
Testing and UAT coordination
Release testing in sandbox previews
Benchmarking and measurement
Adoption reporting, KPI maintenance, QBRs
The traffic flows both directions. BAs who understand admin operations write implementable requirements and hand off cleanly at go-live (Module 14 makes that handoff concrete). Admins who master BA disciplines stop being ticket-takers and become the strategic product managers their organizations need. And people who hold both skill sets, which is exactly what this course is building in you, are the most employable profile in the ecosystem: capable of walking into a small organization as its first Salesforce hire, or into a consultancy as a BA who "gets" the platform.
Recap
Key Takeaways
Admin work rests on five core responsibilities: user management, data management, security, product management, and actionable analytics, approached through repeatable best practices rather than one-off tricks.
Users are created, frozen (instant block), and deactivated (never deleted). Usernames are globally unique; licenses determine features; permission sets carry access while minimum-access profiles carry defaults.
User observation (short, regular, jargon-free sessions across every persona) is elicitation wearing an admin badge, and it is the single highest-leverage adoption habit.
Data loss comes mostly from user error, then sandbox refreshes. Back up data and metadata, test restores, export via Data Export Service or Data Loader, import via the wizard (up to 50,000 records) or Data Loader (up to 150 million, Bulk API for speed), and keep a living data dictionary.
Three releases per year arrive whether you are ready or not. Plan ahead, use pre-release orgs and sandbox previews, mine the release notes with filters, and avoid feature debt.
Feature prioritization scales from a spreadsheet to a three-role process (product owner, platform SME, technical expert), and can be tracked in a custom release-management app inside Salesforce itself.
Analytics becomes actionable through QBR observation, KPI confirmation, and dashboard refresh: tool-agnostic habits that keep data connected to decisions.
Every admin operation has a BA ancestor. Master both and you are the most versatile hire in the room.
📝
Knowledge Check
8 questions. Answer at your own pace, then check the explanation for each.
Question 1 of 8
Which of the following are the five core responsibilities of a Salesforce admin?
Correct answer: B. User management, data management, security, product management, actionable analytics.
Question 2 of 8
A salesperson resigns effective immediately, and she is the recipient of several workflow notifications you need to reassign before removing her account's access permanently. What is the correct sequence?
Correct answer: B. Freeze blocks login instantly without freeing the license; deactivate once the account's obligations are reassigned.
Question 3 of 8
During user observation sessions, admins should:
Correct answer: C. Observation hunts friction in business terms; jargon and solution-fishing contaminate what you learn.
Question 4 of 8
What is the most likely cause of Salesforce data loss?
Correct answer: C. User error leads by a wide margin, which is why backups and import discipline matter so much.
Question 5 of 8
You need to import 2 million records into a custom object on a nightly schedule. Which tool fits?
Correct answer: B. Volume beyond 50,000, a custom object, and scheduling all point to Data Loader with command-line automation; Bulk API accelerates large loads.
Question 6 of 8
An organization ignores new release features for two years. The accumulating shelf of unadopted innovation is called:
Correct answer: B. Feature debt: paid-for innovation left on the shelf.
Question 7 of 8
In the three-role release management model, who leads gathering and prioritizing business requirements?
Correct answer: C. The product owner / business SME leads requirements gathering and prioritization: a role BA-trained people naturally fill.
Question 8 of 8
True or False: Because Salesforce performs extensive regression testing on each release, an org's release testing should focus on user-interface-impacting features and its own custom code.
Correct answer: True. Platform standard functionality is regression-tested by Salesforce; your interface changes and custom code are yours to verify.
🎉
Module 8 complete
Nice work. Review any question again using the menu (top right), or move on.