#Security72 discussing

Same issue on our side. In the footer we only see the total number of records, with no disclaimer. If the report has summed number fields, the totals also appear at the bottom. 

This is clearly linked to how the connector retrieves data for reports with more than 2000 rows. Switching to SOQL queries would fix it, but it means rebuilding many of our Google Sheets dashboards. 

I think the only way to get Google to look at this is to leave as many reviews as possible on the Google Workspace Marketplace page of the add-on. 

Alternatives identified so far:

• SOQL queries in the connector instead of reports. These are not limited to 2000 rows, but the format of the results can differ.
• Paid extensions such as Coefficient or G-Connector for Salesforce (Xappex), which can import reports beyond the limit.
• Apps Script in Google Sheets calling the Salesforce REST API with SOQL and pagination. This is free but needs development and maintenance, and the Reports API would hit the same limit.

If anyone has found another workaround, please share.

Hi @M Anjil Reddy Good question! Profiles provide baseline user access, Permission Sets grant additional permissions, and Permission Set Groups combine multiple permission sets for easier access management.

If a user cannot access an object or field, I would check:

1. Profile: Verify the user's assigned profile.
2. Object Permissions: Check Read, Create, Edit, and Delete access.
3. Permission Sets: Verify assigned permissions.
4. Permission Set Groups: Check group assignments and muting permissions.
5. Field-Level Security: Confirm field Read/Edit access.
6. Record Access: Check OWD, sharing rules, and role hierarchy if the object is accessible but records are not.

My suggestion: Use the User Access Summary to identify effective permissions before making changes.

📘 Salesforce Security Guide – Trailhead

Hope this helps!

@Mit Chandola The KB article you read focuses on User Ownership Skew. When a User owns more than 10,000 records, their position in the sharing architecture is heavily embedded in the platform's security model. If that User changes Roles or is moved in/out of a Public Group, Salesforce must re-evaluate the sharing access for every single record they own. Because the Role Hierarchy or Owner-Based Sharing Rules might now dictate that entirely different branches of the company should (or shouldn't) see those 10,000+ records, Salesforce pushes this massive row-level update to an asynchronous background job to prevent system lockups.  

Queues operate completely differently under the hood:

• No Roles: Queues do not sit in the Role Hierarchy.
• No Public Group Memberships: Queues cannot be placed inside Public Groups for the sake of Owner-Based Sharing Rules.
• Pointer-Based Access: When a Queue owns 500,000 records, the internal [Object]Share tables do not write individual rows for every user in the queue. They simply write one pointer per record where the UserOrGroupId equals the Queue's ID.

When your Flow or Apex adds a user to a queue, Salesforce only inserts a single row into the GroupMember table. The sharing engine dynamically looks at this table at runtime to determine who has access to the queue's contents.

Because the underlying [Object]Share rows for the records are never actually modified or re-evaluated, there is no massive recalculation required. The group maintenance is handled synchronously and nearly instantly. You will not see an async job pop up in the Background Jobs or Setup Audit Trail for this action.

While you don't have to worry about asynchronous sharing recalculation, you should still keep an eye out for Group Membership Skew. If your Apex or Flow is trying to add or remove members from a queue that contains tens of thousands of nested users or public groups, you could hit synchronous CPU time limits or UNABLE_TO_LOCK_ROW errors on the Group or GroupMember tables.

As long as your queue memberships are relatively normal in size, your current automation does not need to be refactored to account for async delays. 

Hi @Durga Prasad Karnaty Even if a user has object access, record-level security may still prevent them from viewing certain Account records.

I would check a few things:

1. OWD: Check whether Account sharing is set to Private.
2. Role Hierarchy: Verify if the user's role provides access.
3. Sharing Rules: Check whether any rules grant access to those records.
4. Manual Sharing: Check if the records are shared with the user.
5. Account Teams: Verify if the user is part of the Account Team.
6. Permissions: Check for View All or View All Data permissions.

Start with Sharing Hierarchy to understand who has access and why, then check the missing sharing permissions.

Hope this helps!

If you're looking for a reliable PST splitter tool to manage large Outlook data files, Kernel for PST Split

is a good option to consider. It helps you divide large PST files into smaller files based on size, date range, or sender's email address. 

The tool also lets you select specific folders for splitting, preserves the original folder hierarchy, and supports both ANSI and Unicode PST formats. Its simple interface makes it convenient for users who want to organize their Outlook data without manually moving emails between files.

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.