How to Secure Your Org in 30 Days: Weekly Updates With Lead Zeppelin

When we think about the word “security”, the first things that probably come to mind are MFA, unauthorized logins, breaches, alerts, and all of that. And yes, security is all of those things – but before we think about all the features that help tighten things up, we have to remember that security is also in the architecture. And if we don’t understand how that architecture works, then you’re going to end up fixing symptoms and stacking more layers onto an already fragile foundation, instead of addressing the root.

So this week, we’re focusing on the very basics: the access model. This is where visibility and capability originate in Salesforce, because setting these up for success means building toward stronger security from the ground up.

Profiles and Permission Sets

Profiles set the baseline for what a user can do inside Salesforce. They dictate the absolute minimum level of access.

The Lead Zeppelin team have begun to lay a good foundation by creating a minimal access Profile for their main users, and have cloned the standard System Administrator Profile and removed some of the more powerful (more potent!) permissions which not everyone needs. More on that later.

Below, we can see a user with the Lead Zeppelin Basic Profile, and nothing else. They have no access to anything at all – which is exactly what we want. Salesforce encourages customers to remove Permissions from Profiles going forward and instead use Permission Sets and Permission Set Groups.

Notably, you can see Lead Zeppelin has a custom System Administrator Profile. The reason for this is that the standard System Administrator Profile cannot be edited, and it contains some permissions that not every System Administrator needs. When you consider the Principle of Least Privilege (more on that very soon!), it doesn’t make sense to be giving some of these very powerful permissions to larger groups of users just because Salesforce puts them inside a standard Profile.

By cloning the System Administrator Profile and restricting the distribution of these powerful permissions to Permission Sets only (i.e. only to the Users that actually require them), Lead Zeppelin is building a strong foundation for their future Salesforce environment.

Permission Sets, on the other hand, layer on top of a user’s profile. They add extra access as needed.

This is where things get a bit more complex for Lead Zeppelin. They really want to build a good foundation for their Salesforce environment, and they’re going about it in a super granular way. For each of their Custom Objects, they’re going with two simple Permission Sets: Basic and Full. Basic grants Read and Edit to the object, and Full gives Read, Create, Edit, and Delete. These do exactly as they say on the tin – basic or full access to the object.

For a long time, most admins didn’t think too deeply about the strategy. The mindset was usually:

1. Give users a Profile that has the access they need.
2. If they ever need more permissions later, just assign a permission set.

And for users who need similar access, just assign the same profile and permission sets to them. Done. However, this is where chaos starts to creep in.

Imagine this scenario: you onboard a new user who needs “almost” the same access as a previous role… except one to two permissions less. So instead of creating a new structured model, you tweak the existing profile. Then, for another user, a little more access is needed, so you create a permission set. Then another. Then another. Before long, you’ve:

• Baked way too much access directly into the profile.
• Layered more and more access on top via permission sets.
• Created org-wide clutter you can’t easily retract or map anymore.

This is how you end up with a messy combination of profiles and dozens of permission sets! It sounds simple and obvious when we talk about it now, but it’s also very real. Back when I was an agent in Salesforce Support, I couldn’t count the number of times we saw this exact situation play out. Without a real strategy, or even a clear understanding of who truly needs what level of access, it’s easy to fall into this trap.

Just thinking about cleaning that up… makes my eye twitch.

Principle of Least Privilege

This is something I want to introduce early on in this series, because it’s crucial for how you set things up and equally important as you maintain them over time. When in doubt, always grant the least amount of access needed for a user to do their job…nothing more! That, in a nutshell, is the principle of least privilege (PLP).

In the context of Salesforce, this means your profile should really just define the baseline identity of a user: who they are in your org. Then, only when necessary, you layer on Permission Sets to grant specific additional capabilities. You don’t need to assign a Sales User a broad just-give-them-everything profile just because “they won’t be actively using the rest anyway”. That’s a recipe for accidental access and data exposure!

Salesforce has been pushing this thinking, especially when they talked about eventually moving away from profiles and making everything Permission-Set driven. That direction is very aligned with least privilege: start small, and add only what is actually required. This reduces over-granting permissions and keeps your access model clean. The key here is, from the very start, to avoid locking yourself into a “one giant profile” pattern that becomes impossible to unwind later.

And while we’re here, there are also specific “critical permissions” (like Modify All Data, Author Apex, etc.) that you should avoid giving out lightly to standard users.

Read More: 10 Crucial Salesforce Permissions You Should Not Assign to Users

This is why Lead Zeppelin cloned their System Administrator Profile and created a custom one earlier. There are permissions that are extremely powerful permissions that Salesforce has attached to the standard System Administrator Profile, and unfortunately, it is not a “one size fits all” scenario. Lead Zeppelin is being proactive in ensuring that only those who have a need for those permissions actually have them.

Using Permission Set Groups

So, say you’ve already set up your profiles for your baseline roles – and then, on top of that, you gave a user a Permission Set to manage Cases, another Permission Set to access Reports, and another one for some admin-level feature they actually need to do their job.

Now imagine you have another user who needs this exact combo.

Of course, you’ll assign them the same profile. But assigning three separate Permission Sets manually leaves room for error. What if you forget one? Or what if someone else on your team assigns “only the two they remembered”, without realizing there was a third Permission Set this role always needs?

With Permission Set Groups (PSGs), you can bundle all related Permission Sets into a single group – then assign that one group to the user. You reduce manual repetitive assigning, and you also reduce the chance of missing a required Permission Set. It’s cleaner, safer, and it scales so much better over time.

As mentioned earlier, Lead Zeppelin has split up their Permission Sets into Basic and Full (Basic being Read and Edit, Full being Read, Create, Edit, and Delete). This kind of granularity can be quite tricky to manage if you’re assigning one-by-one, which is why Lead Zeppelin have also introduced some basic Permission Set Groups.

Once again, these do what they say on the tin – they group together the Basic or Full Permission Sets and layer them together so that users can be assigned what they need. Down the track, they plan on expanding this to different tasks within the system (i.e. distributing an album, writing a song, publishing to a platform) and granting the permissions that are required for those tasks. This way, they can give everyone access to the pieces of the system that they need, and nothing more.

The screenshot below shows the inside of the Full Group Permission Set Group. It contains all those individual Permission Sets that grant Full access to their relevant Object.

By organizing their Permission Sets in a granular manner, Lead Zeppelin are making it easier to grant permissions only to the users that actually need them in the future. As they require more Permission Set Groups, the Permission Sets that they need to assign to them are already there.

Muting Permission Sets

Now that you’re using Permission Set Groups, it’s good to know that it’s also possible to mute specific permissions inside a group! This basically says: “even if this permission exists in one of the included sets… don’t grant it here.” It keeps you from playing around and editing the initial permission sets you’ve already created. Also, it’s useful when you want the convenience of bundling but still want to keep PLP enforced.

Read More: 8 Salesforce Permission Sets Tips

User Access Policies

While we’re on the topic of consolidating permissions for easier and scalable assignments later on, User Access Policies (UAPs) is the ultimate consistency tool that you can use as it lets you automate assignments. For example, “whenever a user is created with the Sales Profile, assign these permission sets”. It’s criteria-based, and what’s awesome is you can also automate revoking permissions with this!

Organization-Wide Defaults (OWDs)

Now you’ve already dictated who can access what objects with Profiles and Permission Sets. But what about records?

Think of it like this:

• Profiles, Permission Sets, Field-level Security = horizontal access (what “surface area” of functionality you can touch).
• OWDs, Roles, Sharing Rules, Public Groups = vertical access (how far up/down you can see into other people’s records).

OWDs are the base layer of record visibility. They define the minimum visibility for each object’s records across the entire org, and you can choose among private, public read/write, etc.

Below is what Lead Zeppelin’s Organization-Wide Defaults look like. You’ll notice that everything is set to ‘Private’ automatically. Does this mean that each user will only be able to see their own records? Not at all! We can layer additional access on top using Sharing Rules… but more on that later in Security Month!

Keeping PLP in mind again, from there you open up access deliberately with the rest of the vertical tools: Role Hierarchy (manager visibility) and Sharing Rules (criteria or ownership-based).

Role Hierarchy

This is where you establish who manages who, and how record access/ownership flows upwards. When you place users in a Role Hierarchy, people above will automatically be able to see (and sometimes edit) records owned by users below them.

But keep this in mind: the Role Hierarchy is not a replacement for good sharing design. Sometimes users mistakenly try to “solve” visibility issues by shoving users higher up – and that’s how you accidentally give someone access to more records than they actually need.

Use roles to reflect reporting structure, and not as a “hack” for record visibility. If someone outside the chain or tree needs access, that’s when sharing rules and manual sharing should come in (stay tuned because we’re discussing these on Week 3).

So, how does Role Hierarchy look like in Lead Zeppelin’s org?

Lead Zeppelin creates music, and they have various team members involved in the different processes. Some of their team are the artists behind the music itself, some are responsible for the distribution of the music once it is produced, and others are involved in the promotion of the new music through events and gigs.

To make sure each person is able to see what they need to see, Lead Zeppelin have crafted a Role Hierarchy that allows each team member to see their own data and the data of anyone who sits under them in the Role Hierarchy.

Week 1 Mission

For existing orgs, you can use the points above as a reference model for your audit:

• Audit your access model:
• Pull a list of all Profiles used in your org.
• Pull a list of all Permission Sets used in your org.
• Identify which ones are truly needed, and consider which ones can be consolidated or retired.

Spotlight any users holding critical permissions (especially Modify All Data or Modify All on specific objects). Confirm that each one genuinely needs it, otherwise, revoke it (Remember the Principle of Least Privilege)! You can use the Access Summary on your user’s page for a consolidated view of what that user can/can’t do.

Read More: 7 Salesforce User Management Best Practices

Lead Zeppelin is doing the exact same thing this week, as they’re mapping out who needs what access in their band’s org before they move on to tightening data visibility. By the end of this week, you should already have a clear understanding of your “baseline” access structure. Tune in next week as we start turning the screws on User Identity and Protection!

Read More: Salesforce Profile Permissions: The Danger Zone

Last week, we discussed the foundation: the basics regarding your users’ access to what. Now that you’ve set your baseline access model, we move on to the next layer: protecting the identity of the person logging in and controlling the environment from which they log in.

“Why is this even important?”, you might ask. That’s because, in Salesforce, your users are the primary entry point. If your user’s identity is compromised, then that equates to compromised data access as well.

So even if you’ve done your best laying out the foundation we discussed last week, and have the cleanest Profiles and Permission Sets in the world, if someone can log in as one of your users…it’s literally game over! Week 2 is laser-focused on strengthening the “front door” to prevent any malicious unauthorized users from entering.

Multi-Factor Authentication (MFA)

For end users, MFA feels like “ah, another login barrier!” but that extra step is exactly what stops a stolen password from immediately turning into a stolen identity. It is not just “another login setting” as it adds an extra verification step on top of the user’s standard username and password login.

MFA is when a user needs to provide two or more different “factors” to prove they really are who they say they are. These can be:

• Something you know (your username + password)
• Something you have (a device or verification method)

For Salesforce, the second factor can be any of these supported methods:

• Salesforce Authenticator mobile app.
• Any TOTP authentication app (Google Authenticator, Microsoft Authenticator, Authy, etc.).
• Security keys that support WebAuthn or U2F (like Yubikey or Google Titan Keys).
• Built-in authenticators on trusted devices (Touch ID, Face ID, Windows Hello).

Compromised credentials are still the #1 cause of org compromise. Someone guessing a password or even accessing a leaked password is not the scary part – the scary part is that without MFA, that simple leaked password or password guess would be enough to log into your org.

Salesforce knows this, and that’s why MFA is mandatory. Everyone logging in to Salesforce via the UI is contractually required to use MFA, but even so, “mandatory” or “required” doesn’t automatically mean “fully enforced”. After all, you are not banned from using your org even if you haven’t enabled it, so in reality, there are still companies that are behind on this. You might want to check Salesforce’s MFA Requirement Checker to assess your compliance, and then this article for the top five methods on enabling MFA.

Let’s take a look at Lead Zeppelin’s Salesforce org again! As you can see, they are enforcing Multi-Factor Authentication with every login through the Salesforce UI. To get into Salesforce, users will need something they know (their username and password) as well as something they have (the authentication code).

This makes it much more difficult for someone to gain access to a Salesforce user. If a password is leaked or discovered by a bad actor, they also need to have access to the authenticator, which is far more difficult.

Login Flows

Login Flows are honestly one of the most underrated identity features. A Login Flow is basically a mini flow that runs at login before users even hit the app. It’s like a pre-gate. So then, users log in > authenticate (thanks to the previous section’s MFA) > the login flow runs > then they get access. It’s a feature that gives admins a powerful surface area to shape behavior right at the point of entry.

There are a whole lot of possibilities with Flow, so adding that to logins? Bam! A world of dynamic checks or actions depending on your business case. Here are some examples:

• • Show a notice/warning/banner on login.

• • Prompt the user to accept the terms of service.

• • Enforce agreements before access (for example: “Don’t export customer data externally”).

• • Conditionally require additional steps for specific profiles.

…and the list goes on! This is also a perfect example of adding friction only where needed, which aligns with the Principle of Least Privilege (PLP) discussed last week. So basically, you create a flow in Flow Builder (usually a screen flow since it requires user interaction), activate it, and then designate it as a login flow for specific profiles.

Example: If you have contractors, you could make their login flow require a second step, while internal users skip it.

Check out this tutorial on creating your own Login Flow!

If you’re logging into Lead Zeppelin’s Salesforce org, you’ll be met with this page as you log in. You will need to read through and acknowledge the warning before proceeding to Salesforce.

Session and Browser Policies

People underestimate this one, to be honest, as it is one of those “quiet” security surfaces that are not flashy, but massively impactful. Session and browser policies control how long someone stays logged in, how their session can be reused, and under what conditions Salesforce will invalidate or force re-authentication. Time is gold, especially for an attacker who’s already “in”. If session policies are poorly set, a stolen token could keep an idle attacker authenticated for hours.

Go into Setup > Session Settings to see a variety of controls you can tune for both convenience and risk reduction. Check out the table below for some key settings you can configure in this section:

Depending on your needs, it’s up to you to strike the balance between convenience (don’t log users out every 15 minutes!) and security (don’t let an attacker ride the same session forever).

For example, first-time MFA users feel that MFA adds friction to the login process, as it is because even if it’s just a few additional seconds, multiplying that by how many times they have to re-authenticate in a day really may take up a significant amount of time. You can ease that burden and strike a balance without weakening security by increasing the Session Timeout value. Read more on this and on customizing logins here.

Trusted IP Ranges

One of the cleanest ways to reduce attack surface is to exercise control right where logins can come from, and this can be done by setting up trusted Login IP Ranges. This is useful especially for businesses that know that their users are always accessing Salesforce from predictable networks, like from their HQ office, for example, or an approved home VPN. Trusted users have the benefit of having easier access to the org, while those outside of the trusted IP ranges will have to go through extra login checks and verification without blocking the user entirely.

Trusted IPs can be set from the Network Access section in Setup, while restricting Login IPs can be done through Profiles.

Lead Zeppelin has decided to implement both a Trusted IP Range for their org and specific IP ranges for their Profiles.

First, the Lead Zeppelin admin went to the Network Access page in the Setup Menu and applied a Standard and End IP Address range for their entire organization. They did this by ensuring they capture all the IPs available through their trusted Virtual Private Network, and will require users to authenticate while connected to the VPN.

Next, they added a series of Login IP Ranges to their custom System Administrator Profile to ensure that only specific computers were able to access the more sensitive user accounts.

Login Hours

Not every org needs to be accessible 24/7, but most orgs are. So, if your business doesn’t operate round-the-clock, ask yourself this question:

Do we really need to allow org access at 2 AM on a Sunday?

If not, then you might consider setting up Login Hours, as these let you set time windows where users can actually log in. If there is any sort of user attempt to log into the org outside those hours, Salesforce blocks it. This can be huge for security because attackers tend to probe at “quiet” hours, or when no one’s online to notice.

Do note that when the login hours are set for the first time on a profile, the time zone follows the org’s default time zone.

Let’s have a look at Lead Zeppelin’s org once more. As you know, Login Hours exist on the Profile itself. Knowing this, Lead Zeppelin created a new Profile for their Songwriters solely because they needed to be given special hours access.

Songwriters do not work on Sundays, so both the Start and End time is set to 12 AM to mitigate this. Monday through Thursday, Songwriters tend to start at 10 AM and wrap up at 5 PM, but can sometimes work a little bit of overtime, so the Login Hours have been set as 10 AM to 6 PM. Finally, they occasionally will work on a Saturday during a Jam Session, so Saturdays have been enabled from 12 PM to 2 PM.

Week 2 Mission

This week’s mission is basically all about “strengthening your front door”. You can use the points above as a reference model:

• Run the MFA Requirement Checker and adjust your setup accordingly.
• Review your Session Settings. Balance convenience with security: longer timeouts to reduce friction, but also don’t allow sessions to live “forever”.
  • • Confirm your timeout isn’t excessive (or too short).
    • Decide if you want to lock sessions by IP/domain.
    • Adjust other settings according to your business needs (check the table for reference on Session Setting features).

• Add at least one Trusted IP Range (even if it’s just your HQ network).
• If your business is not 24/7, set Login Hours accordingly.

Read More: New Salesforce Login Option: Use Your Email Address Instead of Username

Lead Zeppelin is doing the same thing this week: they’re enabling MFA for all internal band members, extending Session Timeout to balance out the MFA experience, and adding Trusted IPs for their studio & rehearsal space. Because even if your access model is perfect…it can take only one compromised login to burn the whole thing down.

And we’re already halfway through Security Month! Last week, we talked about protecting who can get into Salesforce, so this week is about protecting what they can see once they’re in. It’s sort of an extension from Week 1, and we’re diving into the next layer of security: data access and sharing.

Now that you’ve got identity security (MFA, IP restrictions) locked down, your org is primarily guarded against external threats, or the people trying to get in. This week, we turn our attention inward. Data access control protects your org from internal risks, ensuring that even trusted users only see what’s appropriate for their role. After all, maintaining security and compliance should be done both on the inside and out.

Field-Level Security (FLS)

We’ve already set up Profiles and Permission Sets from Week 1, so the baseline level of access for each user is clear. Your second line of defense now is Field-Level Security, which ensures that even if someone can access an object, FLS determines which specific fields they can view or edit.

For example, you might want Sales Reps to view customer details but not see internal cost figures or credit card data. With FLS, you can control this visibility, and it’s configured via Profiles or Permission Sets.

If you want to review your current field permissions, use the View Summary button on your Permission Sets and Permission Set Groups to see every field permission in one place. And if you’re comfortable with querying using SOQL, you can query the FieldPermissions object to audit field access across large orgs. Read more on how to do these here.

Here’s an example of the Permission Set called Song Full that Lead Zeppelin uses to give Full Access to the Song__c Custom Object. Users who hold this Permission set have the ability to Read and Edit all the fields on the Object.

Sharing Rules and Manual Sharing

Also, from Week 1’s Organization-Wide Defaults and Role Hierarchy dictating the baseline access for each object’s records, Sharing Rules are now how you “open the curtains” by selectively allowing access to others when collaboration is needed.

For example, if your Case object is Private by default, that means only the Case Owner can see their Case records. However, if you want all Support Agents to be able to see each other’s cases, you can create a sharing rule based on criteria or ownership.

Lead Zeppelin looks out for people trying to impersonate them, as they’ve experienced quite a bit of this in the past. The Lead Object’s OWDs are set to Private, but Lead Zeppelin wants any Lead that has their domain in the email to be publicly available in their org. They have set up the following Sharing Rule to achieve this.

Sharing Rules are a nice way to balance collaboration and control. Keeping the Principle of Least Privilege in mind, rather than making everything visible to everyone, you deliberately open up access only where it’s needed.

READ MORE: Tips for Planning and Creating Salesforce Sharing Rules

And while we’re on the topic of further customizing record access, Manual Sharing deserves a mention too. If there are scenarios where you need to share a single record with a user (or users), this one’s for you. It’s as easy as clicking the Sharing button while you’re on the record you want to share.

Back when I was still in Salesforce Support, we had countless tickets where someone could see what they weren’t supposed to. Usually, the culprit was, you guessed it, a sharing rule or manual share. At the time, the users didn’t have the Access Summary button, so we often needed to manually comb through sharing settings or trace down the chain.

It’s so much easier now, but this is a reminder to keep manual shares under control (and document them!) or do them only when necessary, so you avoid uncontrolled ad-hoc sharing later.

Restriction Rules

If sharing rules open up access, let’s talk about going in the opposite direction. What if you need to limit visibility beyond the standard sharing model? That’s where Restriction Rules come in, as they let you hide certain records even when other sharing mechanisms would normally make them visible.

Restriction Rules sit on top of your existing sharing model (OWDs + Role Hierarchy + Sharing Rules). They act like a filter. For example, your team can access records of a child object in a master-detail relationship because they also have access to the parent records. This is automatic, as access is “controlled by parent”, right? But what if you only want to selectively share these child records? Then you can use Restriction Rules to determine which child records a user should be able to see, using User/Permission Criteria combined with Record Criteria. Check out this article for a deeper discussion and more use cases for Restriction Rules.

Do note, though, that Restriction Rules are only available for custom objects and only a select number of standard objects (such as Contracts, Events, Tasks, Time Sheets, and Time Sheet Entries). If you’d like to see this feature expanded, there’s an IdeaExchange post you can upvote to request broader support for additional standard objects.

Lead Zeppelin plans to use Restriction Rules to hide new songs from Interns. They know that Song records are only created in the system on their Date of Release, so they are planning on hiding them based on this criteria.

Flow Sharing and Apex Sharing

Sometimes, your sharing logic needs to be dynamic, like granting access based on a process, criteria, or event. Flow is one easy way to handle these cases, and Apex is another.

Sharing Entries

At the heart of Salesforce record access are Share records. These are special records that are actually share entries, stored in objects like AccountShare, OpportunityShare, CaseShare, OpportunityShare, CustomObject__Share, etc. Basically, for all objects where sharing is available, there is also a corresponding share object, and each one has fields that define the object record, who has access to it, and what level of access they have (Read, Edit, or All). Below is a table of the key fields in a Share object:

Using Record-Triggered Flows, you can automatically create (or remove) Share records when certain conditions are met. For example: granting access to an Opportunity when a related field is updated, or revoking it when a deal closes!

The same kind of logic-based sharing that can span across unrelated objects can also be achieved using Apex, where developers can insert or update Share records through code. This method offers immense flexibility, but also requires a developer’s touch. It’s great that admins can use Flow to accomplish similar tasks without having to code, because the concept behind both remains the same: managing record visibility through Share records.

Lead Zeppelin has developed a Screen Flow that allows them to share Account records manually. Below is what the construction of the AccountShare record looks like, which is then inserted into the system to give that user access to those Account records.

Week 3 Mission

This week’s mission is all about visibility:

• Review Field-Level Security by using the View Summary button on permission sets or Access Summary for users. Make sure sensitive fields (like salary, payment details, or personal identifiers) are hidden from roles that don’t need them.
• Check your Sharing Rules and confirm that each one still makes sense. Do retire any rules that are overly broad or no longer apply.
• Explore Restriction Rules to see if there are scenarios where extra filtering would help. Check custom objects with master-detail relationships, as these are usually where “controlled by parent” applies and customization is needed. (optional)
• Understand Share records in Salesforce and experiment with record sharing in Flow for automation-based visibility. You can also do the same with Apex. (optional)

Lead Zeppelin is doing the same thing this week: they’re ensuring users are able to see and edit the fields that they should be able to, making sure records that are not accessible using preexisting sharing functionalities are accessible using Sharing Rules, applying Restriction Rules to keep interns away from records they should not be able to access, and applying advanced sharing by creating Share records in a Flow.

And as usual, always keep the Principle of Least Privilege top of mind: only grant access that is required for the user’s job!

And we’re down to the final week of this series! While the first three weeks were about securing the doors and walls of your org, Week 4 is just as important, and I like to compare it to installing cameras and alarms. It’s all about making sure you can see what’s happening inside.

Even the best security setup needs visibility. This week, we’re looking into building that visibility layer with monitoring tools, audit logs, and tracking that can help you detect suspicious behavior early and investigate when something goes wrong. 

Admin Tools for Visibility

Salesforce gives you native visibility tools that are simple but powerful.

Login History sounds pretty simple: a log of… logins? But really, this is where you can view failed logins, IPs, and even successful login attempts. This matters because it helps you catch unusual activity early, verify user access patterns, and troubleshoot login issues quickly.

You can download the last six months of login history, or filter and view up to 20,000 records from the same period. It can also show the approximate location of the IP address from which the user logged in.

Session Management allows you to see and revoke active sessions. You can view details about each session or delete them if needed, making it easier to respond to compromised accounts or unauthorized access. Location data (approximate only) is also included for each session.

Lead Zeppelin has configured their Session Settings to meet their security requirements. Sessions will timeout after one hour, and users will be forcibly logged out after the session ends. Additionally, all sessions will be terminated when an administrator resets that user’s password. 

One last feature that they’ve turned on is the Lock sessions to the IP address from which they originated. This is a very powerful feature, and not one that should be enabled on a whim. The feature keeps an eye on the IP address that the user is connecting from, and ensures that it doesn’t change during a session. This can realistically only be controlled by using a VPN, ensuring that the IP address does stay static.

Setup Audit Trail, on the other hand, is your best friend when it comes to tracking configuration changes – changes made from Setup like permissions changing, and new fields or objects created. It gives you a clear, searchable history of who changed what and when.

By familiarizing themselves with the Setup Audit Trail, Lead Zeppelin are keeping an eye on what matters most besides making music: keeping track of any changes that occur to their Salesforce metadata.

Automation Security

Automation can also be a hidden security risk. Flows and Apex have the option to run in a system context (meaning they can ignore user permissions), which opens the possibility of unintentionally bypassing field-level and record-level security. Flows can run in system context with or without sharing, and certain elements may still enforce permissions unless you explicitly choose otherwise.

To review and address this, always check whether your automation should run with or without sharing, and when debugging, you can always “Run As User” when possible to confirm whether the automation respects the running user’s access.

Lead Zeppelin have a Flow that they’ve confirmed does NOT need to be run in system context, so they’ve set it to run in System Context with Sharing.

For Apex, write your code with secure operations in mind. Ensure that classes respect user permissions. By using the with sharing notation, you can be sure your code respects the sharing model. If there are classes without this, someone should be able to tell you why. There may be reasons, but respecting the sharing model should be the norm with Apex.

And the new user mode feature can ensure any queries or DML (such as insert, update, upsert, and delete) respect object and field security. This can take the place of Schema.sObjectType.[Object].fields.[Field].isAccessible() calls, which are perfectly viable but are complex. Using one of these options reduces the possibility of accidentally leaking data.

Doing this should give you peace of mind that your automations don’t accidentally expose or modify data users shouldn’t have access to.

Event Monitoring

Event Monitoring provides detailed logs of user activity and org usage, including logins, report exports, API calls, and record views. Even without Salesforce Shield, your org comes with the core Event Monitoring logs that let you review this activity.

Event Monitoring Settings can be found in the Setup menu, and EventLogFile objects can be accessed via Reports, SOQL, or Data Loader.

Common events you can track include:

• APIEvent: for tracking user-initiated read-only API calls.
• ReportEvent: for tracking when reports are run in your org.
• UserRecordAccessEvent: represents a user’s access to a set of records.

For example, using these can help you monitor spikes in API activity that could indicate unusual integrations or automation behavior. By routinely reviewing these logs, you gain visibility into potential anomalies, giving you the chance to act before minor issues become incidents.

Event Monitoring has been enabled in Lead Zeppelin’s org, and they’ve begun configuring the event types that they need to track. 

Salesforce Shield

Salesforce Shield is just as its name suggests: a shield, or an extra layer of armor. It bundles advanced security tools like Platform Encryption, Field Audit Trail, Event Monitoring, and Data Detect, and is definitely something you should look into if your org deals with sensitive data and needs elevated compliance features or data‑sensitivity requirements. Think finance, healthcare, government, or large‑scale partner networks – Shield will for sure be an essential upgrade! It features:

• Encryption of data at rest with your own key management (Platform Encryption).
• Extended field‑history tracking (Field Audit Trail).
• Real‑time and historical event logs of user actions and data access (Event Monitoring).
• Automated detection of sensitive data patterns and exposures (Data Detect).

It’s worth noting that Shield is an add‑on product, meaning additional cost and implementation effort. It’s not required for all orgs, but for those where “good enough” security isn’t enough, it brings deeper visibility and control.

Read More: 5 Crucial Takeaways from the Security Keynote at Dreamforce ’25.

Third-Party Tools & Backup

Don’t overlook your ecosystem! Third-party integrations, backup systems, and sandboxes often hold copies of your data, and that means they can become the weak link.

Having a backup solution matters because there is a possibility of accidental deletions, bad integration jobs, or metadata corruption. All of these are unintentional, but they all lead to data loss. Without a proper backup, recovering quickly becomes very hard. Also, if your sandbox gets seeded with production data, any sensitive information is now in more places, which increases risk unless it’s masked or restricted. Backups are both a recovery tool and a historical audit trail for who changed what and when, especially when you need support for investigations and compliance.

A couple of sample free backup solutions are:

• Peeklogic Backup: Allows you to backup data to Dropbox and save configurations, flows, and metadata to BitBucket.
• Veeam Backup for Salesforce Community Edition: Free for orgs with 50 or fewer Salesforce user licenses. It supports full-data and metadata backups, and allows restoring to production or sandbox.

Week 4 Mission

Check how your org tracks and responds to suspicious behavior.

• Review Login History and Setup Audit Trail for the past month.
• Make sure Flows or any relevant Apex classes run with the right security context.
• Verify that your Sandbox data is secure and you haven’t carried over any sensitive data from Prod.
• If possible, explore setting up Event Monitoring and create a report to get visibility on relevant event logs.
• Monitor user activity.
• Know what integrations and third‑party tools have access to your data, and make sure backups exist.

Read More: Why Your Salesforce Org Is Less Secure Than You Think