#Security156 人がディスカッション中

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

Hi @Rohit ., 

A suitable Salesforce security approach would be:  

• Country-wise visibility: Use OWD + Roles/Sharing Rules to control access by country. 
• Managers: Use the Role Hierarchy so managers can access subordinate records. 
• HR: Keep HR records restricted using Private OWD + Restriction Rules/Sharing as required. 
• Legal: Provide access to high-value Opportunities through Criteria-Based Sharing Rules. 
• Finance: Assign a Read-Only Permission Set/Profile. 
• Partners: Use Experience Cloud with appropriate sharing sets/rules so partners see only their own records. 
• CEO: Place the CEO at the top of the Role Hierarchy with appropriate access. 
• Auditors: Provide temporary access through appropriate permission sets and sharing, with access removed after the audit. 

This follows the Salesforce security model by combining OWD, Role Hierarchy, Sharing Rules, Restriction Rules, Profiles/Permission Sets, and Experience Cloud sharing based on each requirement. 

Hope This Helps!! 

Hi @Rohit .

You can handle this using a

and block further updates for Sales Users, while allowing specific users such as System Administrators to edit it.  

This is generally a better approach than relying only on page layout settings, because the validation rule enforces the restriction when the record is saved.  

Hope this helps! 

@Hitesh Sharma  

Yes. A single Restriction Rule can apply to multiple Managers. You don't need one rule per user. 

Use a shared attribute such as Location and make the rule apply to the Manager group/role, for example: 

User.Location__c = Employee.Location__c

Then all 10 Managers can use the same rule, provided each Manager has their own Location value. 

excluded from the restriction, so they can see all Employee records. 

So the design is: 

Hi Salma, 

This community can't reset passwords or security questions directly — that has to go through the proper account recovery channel. Which one applies depends on what kind of account this is: 

1. Trailhead/Trailblazer account: Go to

2. A company/work Salesforce org: Only your org's Salesforce Administrator can reset your password and security question for you — this can't be self-served or done by Salesforce Support directly, since it's your employer's org, not a personal account. 

Hi @Pranjal Budhlakoti, 

Adding On 

@Hitesh Sharma & @Rohit .

No, View All does not automatically give access to every field on an Opportunity.

View All is a record-level permission. It allows the Manager to view all Opportunity records, regardless of OWD, sharing rules, role hierarchy, or ownership. 

However, Field-Level Security (FLS) controls whether the Manager can see or edit specific fields. Therefore, if the Salary field is hidden from the Manager through FLS, the Manager will not be able to see that field even though they have View All on Opportunity.

In this scenario:

• OWD = Private → controls baseline record access.
• View All → Manager can view all Opportunity records.
• FLS → still controls visibility of individual fields.
• View All does not override FLS.

So the key point is: Record-level permissions and field-level permissions work independently.