#Security토론 중인 항목 132개

Hi @Shiv Murti Pal

To resolve this issue, please check the following Salesforce security settings:

1. Role Hierarchy: Ensure the Sales Manager's role is above the team members' roles so the manager can access their Opportunity records.

2. Organization-Wide Defaults (OWD): Check the Opportunity sharing setting. If it is Private, verify that the Role Hierarchy provides the required access.

3. Sharing Rules: Review Opportunity sharing rules to ensure records are shared with the appropriate users or roles.

4. Other Permissions: Check Permission Sets, Profiles, and Restriction Rules that may affect record visibility.

Recommended Solution: Start by checking the Role Hierarchy and Opportunity OWD settings, then review the sharing rules.

Hope this helps! 🙂 

Hi Piyush, 

1. You're right, mTLS is the wrong tool here. mTLS operates at the application/TLS layer after a TCP connection is already established — it proves identity to something that's already listening and accepting connections. If the vendor's firewall is dropping packets before that handshake even starts, no client cert changes that. mTLS solves "who is this," not "can this even reach me." 

2. Private Connect is AWS PrivateLink-based only, so it's natively usable when the target sits in an AWS VPC. Azure targets aren't natively supported — you'd need inter-cloud private peering (AWS↔Azure via ExpressRoute/Direct Connect + a transit arrangement) which Salesforce doesn't self-serve; that requires your account team and is a heavier lift. No public roadmap confirmation of native Azure PrivateLink support as of now. 

3. No native mechanism gives an Apex callout a narrower/tenant-specific egress identity beyond the published IP ranges — that's the actual gap you've identified. The published Hyperforce ranges are deliberately shared infrastructure-wide, not per-org, so it's a network-layer allowlist, not an identity boundary. There's no equivalent of "static NAT per org" for outbound Apex callouts today. 

4. Yes — a relay/gateway in front of the private service is the standard, recommended pattern here, and I'd recommend it. Put a lightweight reverse proxy (or MuleSoft Anypoint, or even a small managed API gateway) in a publicly reachable spot the vendor controls, with the vendor's actual private-network service sitting behind it. Salesforce calls the gateway over the public internet (allowlist-friendly, small surface), and the gateway — sitting inside the vendor's trusted network — forwards to the private endpoint. This gets you real identity-based control (API key, mTLS, OAuth — now actually meaningful since the gateway is an app-layer listener) instead of a shared-IP-range network allowlist, and it decouples you from Salesforce's outbound range changes entirely, since your callout target becomes a stable endpoint the vendor owns. This is what most orgs land on for exactly this scenario — it's a small piece of infra to own, but it's the durable fix. 

Reference:

@brantley hobbs

Salesforce publishes these in the Help article 'IP Addresses for Inclusion on Allowlists in Marketing Cloud Engagement' — the ranges are instance-specific and Salesforce changes them periodically, so pull the set for your instance and re-check it quarterly. On what you're seeing: the 's12' in

Hi Sans, 

This looks like a known issue tied to a recent release, not something wrong with your setup. Salesforce has an open issue where changing a user's email post Summer '26 causes the verification link to redirect to the login page instead of completing the change, and the email address stays unchanged even after the user clicks "Verify Email Address." 

Official reference:

Workarounds from that same official issue page, in order of ease: 

1. Edit the user record, remove the ".invalid" suffix or enter the new email address, and while still in edit mode, check "Generate new password and notify user immediately." This sends a reset email that lets the user verify the email and set a password in one step. 

2. If the user gets redirected to login and is then prompted for a verification code sent to the OLD email, have them enter that code, this completes the update even though the "click the link" flow appears broken. 

3. If the user can log in via SSO, have them establish a session via SSO first, then click the verification link. 

4. If none of the above work, an admin can set a temporary password using System.setPassword() for that user, then reattempt the email change. 

5. As a last resort, set Trusted IP Ranges for the org, or add a phone number to the user's record. Both have resolved this for others per the same article. 

Separately, on your question about the ".invalid" suffix: this is expected sandbox behavior, not a bug. Every sandbox refresh or clone automatically appends ".invalid" to all User email addresses so production users never receive automated emails from sandbox testing. You have to manually remove ".invalid" per user if you want that sandbox user to send/receive real emails. 

Official reference:

On your last question, multiple users with the same email address: Salesforce does not enforce email uniqueness the way it enforces Username uniqueness. Username must be globally unique across all of Salesforce, Email does not have that same platform-level restriction. 

Official reference (Trailhead, Salesforce-authored):

So 3 users sharing one email address is technically possible, but keep in mind: whichever user's "Email" field matches will all receive password reset emails, report subscriptions, and notification emails to that same inbox, so this is only advisable for non-production/test scenarios, exactly what you're doing in this sandbox.

 Hi @Rohit .

The best approach is Field-Level Security (FLS) with a Finance Permission Set. 

•  Remove Read/Edit access to the Salary field for non-Finance users. 
•  Create a Finance Permission Set and grant Read Access to Salary. 
•  Assign this Permission Set only to Finance users. 
•  Use Page Layouts only for UI visibility; they should not be used as the primary security control because FLS also controls access through reports, list views, search, and API. 

This ensures that only Finance users can access the Salary field, while other users can still access the Employee records without seeing Salary. 

Hope This Helps!! 

 Hi @Rohit .

Yes, this can be achieved, but not using FLS alone.  

FLS is applied at the user/profile/permission-set level, so it cannot dynamically show a field based on whether the Employee record belongs to the logged-in Manager or to a subordinate.  

For example, if a Manager has FLS access to Salary, that field access applies to Employee records the Manager can access. FLS doesn't provide a rule like: 

My own record → show Salary 

 Subordinate's record → hide Salary 

The Role Hierarchy controls record-level access, but it doesn't provide field-level restrictions based on record ownership.  

For highly sensitive information such as Salary, PAN, and Bank Details, a better approach would be to keep the confidential information in a separate custom object and control access to that object/records using OWD, sharing, roles, and permission sets.  

If the requirement is only to hide fields from the Lightning UI, Dynamic Forms or an LWC with conditional visibility can be considered, but UI hiding should not be treated as a security mechanism. 

So the key distinction is: 

FLS → Which fields can the user access? 

 OWD/Sharing/Role Hierarchy → Which records can the user access?  

Hope this helps! 👍 

Hi @Rohit .

Since you can already open the App Launcher but don’t see apps such as Sales and Service, I would check the app assignment and visibility settings first. 

1. Check the user's Profile / Assigned Apps 

Go to: 

 Setup → Users → Profiles → [User's Profile] → Assigned Apps 

Make sure the required Lightning apps, such as Sales and Service, are assigned/visible to that profile. Salesforce confirms that users only see apps they’re authorized to access through their profile or permission sets. 

2. Check App Manager 

Go to: 

 Setup → App Manager 

Find the Sales or Service Lightning App and verify that it is configured for the appropriate user profiles.  

3. Check App Menu visibility 

Go to: 

 Setup → App Menu 

Verify that the apps are Visible in App Launcher, not Hidden in App Launcher.  

4. Check object/tab permissions 

If the app is visible but some tabs such as Accounts, Contacts, Opportunities, or Cases are missing, check the user's Profile/Permission Sets → Object Settings → Tab Settings and Object Permissions. Tab settings affect whether objects appear in the Lightning App Launcher and navigation menus. 

So I would check these in this order: 

Profile/Permission Set → Assigned Apps → App Manager → App Menu visibility → Object & Tab permissions 

If all of these look correct and the issue still occurs, then we can check the user's license and app configuration as the next step.  

Hope this helps! 👍 

Hi @Rohit .

If you are trying to test the newly created user's access using Login As, first make sure you are actually using Salesforce's Login As feature rather than logging in with the administrator's own username/password. 

As a System Administrator, go to:

Setup → Users → Users → find the user → Login 

Salesforce will then open the org in that user's context, so you can verify the user's actual profile, permissions, and access. The Login link is available when the user has granted login access to the admin, or when Administrators Can Log in as Any User is enabled.  

You can enable it from:

Setup → Login Access Policies → Administrators Can Log in as Any User

Save the setting. Salesforce requires the appropriate admin permissions, including Modify All Data and Manage Users, for this capability.  

Also, if you are testing the user's permissions, check the user's Profile, Permission Sets/Permission Set Groups, License, and Role. These determine what the user can actually access. 

 The user's profile doesn't change when you use Login As. You are simply viewing Salesforce as that user. So if you see the System Administrator profile while logged in, make sure you are not simply using the administrator's session or credentials instead of the Login option from the User record. 

Hope this helps! 👍