#Salesforce Developer397 utenti parlano di questo argomento

Hi everyone,

I’m looking for some advice on a Salesforce security/architecture scenario. 

We have a group of Sales users whose Account access is granted through criteria-based sharing rules based on the entity/company they work for

. For example, users belonging to different country entities receive access to the corresponding Accounts. 

These users are also assigned to a Permission Set Group that grants Read access to a number of financial fields on the Account object

. 

The business requirement is to restrict these users from creating or modifying Reports, exporting Report data, and accessing restricted company-wide financial Reports and Dashboards.

At the same time, they must retain their existing visibility when working with an individual Account they have access to, including the relevant financial information, Invoices and Orders.

This leads to a question around the same financial fields being available through different Salesforce surfaces.

If a user has FLS Read access to these Account fields so that they can see them on the Account Record Page:

Is there any standard/native Salesforce mechanism to prevent those fields from being available in List Views, while still allowing them to be displayed on the Account Record Page?

And regarding Reports:

If the user is allowed to run a centrally provided Report, is there a standard way to prevent the financial fields from being exposed through that Report while keeping the user's existing Account-level visibility? 

We explored using Custom Report Types to exclude these financial fields from the layout. However, if an Inside Sales user runs a centrally provided Report built on a report type that does

include these fields (because Outside Sales and Management users share the reports and need them), Salesforce will render the data for the Inside Sales user too, as long as their FLS is active. Salesforce does not support dynamic column masking or role-based field filtering within a shared Report Type. 

Or is the standard Salesforce security model that FLS applies globally across all these surfaces, with Report/Dashboard folder access and export permissions providing the only standard restrictions?

I’m interested specifically in the standard Salesforce capabilities, or is this only possible per custom and if yes, how? LWCs? 

Thanks! 

In our Salesforce org, we are seeing the following notification: 

We checked our Einstein Activity Capture (EAC) settings and noticed that Google G Suite

is currently connected. We do not have a Microsoft Outlook account connected to EAC. 

Based on this configuration, we have a couple of questions:

1. Since our EAC configuration is using Google G Suite, do we still need to upgrade the authentication method from Exchange Web Services (EWS) to Microsoft Graph API?
2. Since Outlook Integration & Sync is enabled, does this require us to migrate from EWS to Microsoft Graph API even though Google G Suite is the connected account in EAC?
3. If the Microsoft Graph API upgrade is still required, what is the recommended authentication level/permission level that should be configured for the Salesforce app in Azure?
4. Is there any impact on our current EAC functionality if we continue using Google G Suite and do not have Microsoft Outlook connected?

I have attached screenshots of our current configuration for reference. 

Any guidance from someone who has already handled this EWS retirement transition would be greatly appreciated.

#Einstein Activity #Einstein Activities Capture #EAC #Salesforce Admin #Salesforce Developer

The list view for Accounts is not showing correctly and is reduced to only four records. It is neccessary to scorll through the short list view to view all data. How can this defect be reversed? 

Additionally, fhe filters and charts do not show. It opens just a blank section. It seems to be a bug. 

Does anyone have an idea how to resolve this issue?  

Your feedback is highly appreciated.  

#Salesforce Admin  #Salesforce Developer  #Trailhead Challenges