#Security75 debatiendo

Object level settings for Account Contact Relationships is controlled by Account and Contact objects. 

To create, edit, or delete Account Contact Relationships you would require Read on accounts and Edit on contacts. 

To view Account Contact Relationships you would require Read on accounts and contacts. 

Related documentation:

Glad you got it working. What you found points to the actual cause, though: the server isn't sending the GoDaddy intermediate certificate along with yours. Chrome and Edge quietly fetch a missing intermediate on their own, so the site looks fine in the browser. Tableau Desktop doesn't do that, so it fails unless the intermediate is already in that machine's certificate store, which is why installing the .p7b fixed that one PC.  

It may also explain why it broke exactly at renewal: GoDaddy has been moving renewals to a new intermediate (R1), so if the server still has the chain file from the old certificate, it won't match the new one.  

If you fix it on the server instead, you won't have to repeat it on every Desktop machine. Tableau Server wants PEM files, not the IIS ones. Download the certificate again from GoDaddy and choose Apache (or Other) as the server type, which gives you your .crt plus a second file with "bundle" in the name. That bundle is the chain. In TSM go to Configuration > Security > External SSL, add it as the certificate chain file next to your cert and key, save and apply pending changes.  

Or from the command line:  

tsm security external-ssl enable --cert-file .crt --key-file .key --chain-file tsm pending-changes apply  

To check what the server sends: openssl s_client -connect yourserver:443 -showcerts. You should see your certificate and, under it, GoDaddy's intermediate (the bundle can add a cross-signed root too, so two or three is fine). If only yours shows up, the chain isn't being sent. Applying the change restarts services, so do it out of hours 

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!