#Security138 discutindo

@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! 👍

The update clarifies that the Malicious Files list view was a backend/internal view and was not actually indicating that those PDFs had failed a malware scan. 

If the Malicious Files list isn't visible in the Files app from the App Launcher, Salesforce Support indicated that there are no files currently flagged as malicious. 

So this appears to be a Salesforce UI/list-view issue rather than an issue with how the PDFs were uploaded

.  

Hi @Rohit .

Restriction Rules alone won’t satisfy this requirement, as they can only restrict existing access, not grant access.  

A better approach would be: 

•  Set OWD to Private for Employee. 
•  Give HR users access to all Employee records using appropriate sharing or View All permission. 
•  Give Managers access to employees in their own Location using criteria-based sharing or Apex Managed Sharing for dynamic requirements. 

Use sharing mechanisms to grant access, and Restriction Rules only when additional record-level restriction is required. 

Hope This Helps!!