BA Academy — self-paced module
By the end of this module, you will be able to:
It would be easy to file "security" under admin work and skip ahead. Resist that. Security requirements are requirements, and eliciting them is your job. Every "who can see what" sentence a stakeholder utters is a security requirement: "interviewers shouldn't see salary data," "volunteers can only see their own hours," "managers need visibility into their whole team's records." In Module 4's WellCare case study, the acceptance criterion "only the sales rep who owns the lead, and people above them in the hierarchy, can change the stage" was a security requirement hiding in plain sight. This module teaches you the vocabulary and mental model to hear those requirements, ask the right follow-ups, and document them precisely.
There is a second reason. Choosing which data each user can see is one of the key decisions affecting the security of any org, and it involves a permanent tension: balance security against convenience. Lock everything down and people cannot do their jobs; open everything up and you risk stolen or misused data. The platform's flexible, layered sharing model exists to resolve that tension: giving thousands of users just the right access without specifying permissions user by user. Understanding the layers is what lets you have intelligent conversations about the trade-offs.
One reassuring engineering fact before we start: the security model works at the API level, not just in the user interface. Whatever permissions are configured apply even when data is accessed programmatically or through integrations. There is no back door around a properly configured model.
Throughout this module we will use the scenario Salesforce's own security training uses: a recruiting app managing open positions, candidates, job applications, and interview reviews. It stores genuinely confidential data (social security numbers, bonus amounts, candid interviewer assessments) that only some users should see, and it serves four kinds of users:
The design challenge: secure the sensitive data without making life harder for any of these people. Keep the four personas in mind; every concept below will be illustrated against them.
Salesforce controls data access at four levels, from broadest to finest:
Combining controls at different levels produces precise results. For example: an interviewer can log in during business hours (organization), can view positions and job applications but not edit or delete them (object), cannot see bonus or social security fields (field), and sees only reviews she herself wrote (record).
A practical tip straight from the source material, and one of the best BA habits in this entire course: make a table of the types of users in the organization, and specify each type's required access to every object, and to fields and records within it. That table, sometimes called a security matrix or access grid, is a discovery deliverable a BA can own completely, and the admin or architect will build from it gratefully.
At the broadest level, you protect the org by managing who can log in, and when and where they can do it.
Every Salesforce user is identified by a username, a password, and a profile. Creating a user takes a few clicks: name, email, a unique username in email format, a license (which determines available profiles), and a profile. Salesforce generates a password and notifies the new user.
You cannot delete a user in Salesforce: history and record ownership must stay intact. Instead you deactivate users, which frees their license and removes all access. When something urgent happens and you cannot immediately deactivate (for example, the user is the recipient of workflow notifications you first need to reassign), you can freeze the account: login is blocked instantly while you tidy up, then you deactivate properly. Deactivating former users promptly is one of the most basic and most neglected security practices; dormant accounts of departed employees are a classic attack vector.
Admins set org-wide password requirements: minimum length, complexity, history (no reusing recent passwords), expiration, and what happens after failed login attempts. Guidance from the National Institute of Standards and Technology (NIST) informs current best practice, and two habits matter most:
MFA requires multiple forms of authentication: something you know (password) plus something you have (a code from a mobile authenticator app, or a security key). Salesforce requires MFA for access precisely because stolen credentials are a top attack vector: a stolen password alone should never be enough to get in. As a BA you will simply live with MFA as a user, but you should also expect it to appear in requirements ("all external portal users must use MFA") and in Health Check findings.
Two more org-level controls:
These sound draconian until a client in finance or healthcare asks for them; then they are Tuesday. Knowing they exist lets you capture such requirements without blinking.
Object-level security is the simplest broad control: for each object, a user either can or cannot create, read, edit, or delete records of that type. In the recruiting app, object permissions ensure interviewers can view positions and job applications but never edit or delete them.
Three constructs deliver these permissions. Their division of labor is the single most misunderstood part of Salesforce security, so here it is cleanly:
This is the permission-set-led model, and it embodies the principle of least privilege: users, devices, and applications get the minimum access necessary to do their jobs, no more. Why it won: with profile-led security, organizations bred dozens or hundreds of near-duplicate profiles, each a maintenance hazard. With permission sets, access is composed from small, reusable, task-shaped blocks: build once, combine per persona, mute the exceptions. Reduce the number of profiles; prioritize permission sets.
Here is how the four personas' needs translate into object permissions:
| Object | Recruiter | Hiring Manager | Interviewer | Standard Employee |
|---|---|---|---|---|
| Position | Read, Create, Edit | Read, Create, Edit (own positions) | Read (no bonus fields) | Read (no bonus fields) |
| Candidate | Read, Create, Edit | Read (their positions' candidates; no SSN) | Read (assigned only; no SSN) | No access |
| Job Application | Read, Create, Edit | Read, Edit (status only) | Read (assigned only) | No access |
| Review | Read, Create, Edit | Read, Create, Edit | Read, Create, Edit (own reviews) | No access |
Study the nuances, because they preview every other level of the model:
Field permissions (field-level security, or FLS) control whether a user can see or edit a particular field, even on objects they can otherwise access. This is how you protect a candidate's social security number without hiding the whole candidate record.
The critical distinction: page layouts only control what appears on detail and edit pages. Field-level security controls the field everywhere: related lists, list views, reports, and search results. Hiding a field from a layout is cosmetic; a user can still reach the data through a report. To truly restrict a field, use field permissions. There is no shortcut that provides equivalent protection.
Recruiting app examples:
Field permissions live in permission sets (recommended) alongside object permissions. A worked illustration: an "Update Candidate Records" permission set for interviewers grants Read on the Candidate object, lets interviewers read and edit the skill-assessment checkboxes they fill in after interviews, grants read-only visibility on the hire-by date and hiring manager fields, and grants no access at all to SSN, email, or phone. One permission set captures an entire task's worth of nuanced access.
For the BA: field sensitivity is discovery gold. Whenever a stakeholder mentions salary, health information, government IDs, donor giving capacity, or anything that makes someone in the room lower their voice, capture who may see it, who may edit it, and who must not: those sentences become FLS configuration.
Now the finest-grained question: among records of an object a user can access, which individual records can they see and edit? Object permissions grant a baseline; record-level security controls access to records a user does not own.
Four tools control record access, in order of increasing access. The strategy is always the same: lock data down to the most restrictive sensible default, then selectively open access back up.
Org-wide defaults specify the baseline access users have to records they do not own, set per object. The setting should represent the access appropriate for the most restricted user. Four possible values:
To choose, ask three questions per object: Who is the most restricted user of this object? Is there ever a record of this object they should not see? Is there ever one they should not edit? For the recruiting app's Position object: the most restricted user is a standard employee; every employee may see every position (referrals are welcome); but employees must not edit positions. Answer: Public Read Only. Candidates and reviews, by contrast, go Private.
Two rules to engrave: OWD can only restrict relative to object permissions, never grant more. And everything after OWD (hierarchy, sharing rules, manual sharing) can only open access up, never tighten it further. If the default is Public Read/Write, no sharing rule can claw it back.
The role hierarchy grants users access to all records owned by users below them in the hierarchy: managers see their teams' records automatically. In the recruiting app: the CEO sees everything; the VP of Human Resources sees whatever her recruiting manager and his recruiters own; the software development manager sees records owned by his engineers.
The most important design insight: the role hierarchy is not your org chart. Each role represents a level of data access, not a job title. Consolidate titles that need identical access into one role (a staff engineer and junior engineer become one "Software Engineer" role). Start from the org chart, then simplify ruthlessly.
One escape hatch to know: for custom objects, an admin can disable "Grant Access Using Hierarchies," so that even bosses do not automatically see subordinates' records: useful for genuinely sensitive data (peer feedback, ethics cases).
Sharing rules create automatic exceptions to org-wide defaults for defined groups of users: they grant access to records those users do not own and could not otherwise see. Like the hierarchy, sharing rules only ever grant; they can never be stricter than the OWD.
Every sharing rule answers three questions:
The design wisdom: sharing rules work best for groups you can determine or predict in advance. Recruiting app walkthrough: "all recruiters need read/write on every recruiting record" is a perfect sharing rule, because recruiters are cleanly identified by role. "Interviewers need access to candidates for people they're interviewing" is a terrible sharing rule, because interview teams change per position and cannot be predicted: that case calls for a different tool (manual sharing, or team-based features).
Record owners (and users with sufficient permission) can share individual records ad hoc via a Share action. Not automated, but perfect for the unpredictable cases: a recruiter heading out on vacation shares her open job applications with a colleague; a hiring manager shares one sensitive position record with a finance partner for budget review. Manual sharing is the release valve for everything the systematic tools cannot predict.
The complete access calculation for any user and any record:
When you can narrate that five-step story aloud, you understand Salesforce record security better than a good many working consultants. And notice what the tools ask you for: "who reports to whom" (hierarchy), "which groups always need what" (sharing rules), "what's the default for people with no special relationship to the record" (OWD): all questions a BA answers during discovery.
Configuration is half of security; verification is the other half. Someone in every organization should regularly audit for unexpected changes or patterns of use. Salesforce provides layered tools:
For larger or regulated deployments, Salesforce Shield adds premium protections: Platform Encryption (encrypting data at rest while preserving functionality), Field Audit Trail (retaining field history far longer for compliance), and enhanced Event Monitoring. Transaction Security policies go a step further: they can intercept risky behavior in real time and block it or require additional authentication (for example, halting a report export of ten thousand records). BAs on healthcare or financial projects should expect these names in requirements conversations.
Salesforce Health Check is a dashboard in Setup that assesses an org's security settings against Salesforce's recommended baseline and produces a score from 0 to 100. It compares each setting's current value against the standard value, flags gaps, and provides Edit links to fix each finding, plus a Fix Risks button that applies recommended values in bulk.
Use it wisely:
For a BA, Health Check is a discovery instrument: on any project touching an existing org, ask when Health Check was last reviewed and what the score is. The answer tells you a great deal about the client's security maturity, in one number.
Salesforce approaches security with a defense-in-depth strategy: many layered controls, so that if one fails, another still protects the asset. Security is a joint responsibility: Salesforce secures the infrastructure; the customer (meaning admins, and the BAs writing their requirements) secures the configuration.
What the platform provides beneath your configuration: multitenancy isolation (one pool of computing resources serves many customers, with each org's data partitioned by unique identifiers bound to every user session), Transport Layer Security (TLS) encrypting data in motion, and hardened, secured server environments. You will never configure any of that, but clients ask about it ("is our data safe in the cloud?"), and the honest answer is that the platform layer is world-class, and nearly all real-world Salesforce breaches trace to configuration, credentials, or people. Which brings us to the last and most important layer.
Modern attackers target people, not just technology. Phishing and stolen credentials remain top threat vectors year after year, and a single employee opening one malicious email can compromise an entire company's data. Security training is not a compliance ritual; it is the cheapest, highest-return defense that exists. Every person affects security, regardless of function or title.
Social engineering works by triggering normal human feelings:
If a message makes you feel a strong urge to act right now, that urgency is itself the red flag.
Since this course exists to launch remote careers, treat this section as personally as anything in the program. Working from home in Puna, you are your own IT department:
A note on AI, consistent with this course's high-level treatment: as orgs adopt AI agents and assistants, the same security model does the protecting: agents act within the permissions and guardrails they are given, and platform trust layers apply protections such as masking sensitive data before it reaches external models. The security requirements conversation from Module 2 (what may the agent see, do, and refuse?) is this module's material wearing new clothes.
Bring these questions to every project:
Document the answers in a user-type access table, hand it to the architect and admin, and you will have delivered one of the most valuable artifacts a discovery phase can produce.
8 questions. Answer at your own pace, then check the explanation for each.
Nice work. Review any question again using the menu (top right), or move on.
Continue to Module 8: Salesforce Admin Operations (User & Release Management) →