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

Hi @ROHIT PIPPERA

As a fresher, you don't need advanced knowledge of Salesforce security, but you should be strong in the basics. 

Focus on these key concepts:

1. OWD: Understand Private, Public Read Only, and Public Read/Write.
2. Role Hierarchy: Know how managers can access their team's records.
3. Sharing Rules: Understand how to provide additional record access.
4. Profiles: Learn about baseline user permissions.
5. Permission Sets: Know how to provide extra permissions without changing profiles.
6. Field-Level Security: Understand how to control field visibility and edit access.

My suggestion:

 Don't just learn definitions. Create a few users in a practice org and test different security scenarios. 

Interviewers may ask why two users with the same profile can see different records or why a user can view a record but cannot edit it.

If you can explain these scenarios confidently, you're well-prepared for fresher-level interviews. 

All the best! 

Thank you, 

Venkat Yadav.

@Lena Wong

You're right the business rule doesn't care who owns the Quote. The risk comes from how the platform stores the share, not from the rule. 

Where the Quote owner matters (platform mechanics, not business logic) 

A Flow created QuoteShare is a manual share (row cause "Manual"). Salesforce deletes manual shares on a record when that record's OwnerId changes. Your Flow most likely triggers on events like Quote created or Account owner changed. A Quote owner change isn't one of those events, so: 

1. The ERP (or a user or mass transfer) changes the Quote's owner.
2. The platform silently deletes the share the Flow created.
3. Nothing re-runs the Flow, so the Account Owner loses access even though the business rule says they should have it.

Fixes, in order of preference: 

• Add a trigger path on Quote update when OwnerId changes, so the Flow recreates the share.
• Add a scheduled reconciliation that compares expected and actual shares. This also catches other drift.

A related edge case:

if the Account Owner is also the Quote owner, they already have access. The Flow should skip creating the share in that case, because inserting a share for the owner is rejected or ignored. 

(it creates Quotes under a fixed integration user and never updates them), this risk mostly goes away, and the Account owner, region, and bulk-load gotchas are what remain. I can't confirm that from here, so it's worth asking the ERP team. 

If every sales user is in the same Permission Set Group, that group can't tell Field Sales from back-office, so it doesn't help as the identifier. Option 2 only works with a separate, standalone permission set (for example

@Mohanraj S

we recently also had an issue in a Sandbox for a user we wanted to update email. The email update went into a loop that did not work.  

After working with Salesforce support, what unblocked us was to clear cache in that case.  

Previous checks: 

1. Verify that user was not frozen.
2. Confirmed through screen share they were following the steps required to update email.

Once pasting the email ina private window web page, they were able to complete the process. 

Thank you for the suggestion. I followed the steps in the link about clearing them manually, but for some reason, the error persisted. In the end what solved the problem was this: the certificate files we were using were IIS files, and came in the form of a .crt file, a PEM file, and an IIS intermediates .p7b file. I installed the CRT file to the user's certificate stores without a problem, but when I attempted to install the p7b file, Windows said it could not verify that the file was actually from GoDaddy (despite my having downloaded the file directly from the site). I had the machine install the file to the certificate store anyway, and afterwards Tableau Desktop was willing to start and activate properly. 

A work colleague has shared another alternative solution with me. 

In Setup → Session Settings → Session Security Levels, move Passwordless Login via Passkeys to the High Assurance category. 

Why does this work? 

Salesforce allows us to define which authentication methods establish a High Assurance session. By classifying Passwordless Login via Passkeys as High Assurance, users who log in with a passkey start their session at that security level. 

As a result, when they perform sensitive operations that require High Assurance, Salesforce doesn’t prompt them to verify their identity again during the same session: 

If you require high assurance for sensitive operations and users have a high-assurance session after logging in, they aren’t prompted to verify their identity in the same session.

The list of affected operations and the corresponding configuration can be found here: Require High-Assurance Session Security for Sensitive Operations

 Hi Kevin, 

 for opening an external website from an LWC, you don't need any CSP/Trusted URL configuration that's only required when the LWC needs to call an external endpoint or load a remote resource . Simply navigating the user's browser to an external URL in a new tab is just standard browser navigation and Salesforce doesn't mediate it. you can use a plain anchor tag with rel="noopener noreferrer". 

 I hope this help!!

We are migrating to SOQL, meaning we will use the same Google Connector to query the data directly instead of exporting reports. Because this SOQL export operates via the API rather than the UI, it successfully bypasses the mentioned limitation.

However, please keep the following SOQL specifics in mind:

• Row Limits: Extracts are capped at 10,000 rows.
• Headers: Google Sheets will display field API names instead of standard field labels.
• Formatting: The column order in the sheet may not match the order of fields in your query.

Despite these quirks, this remains a highly effective workaround.