Transaction Security Policy - Block "ReportRunFromLightning" Operation Based Object By RecordType Counts

Question

I'm reaching out to my fellow StackExchange community members for help to determine if Shield Event Monitoring or some other solution can solve my business problem.  Here we go.

• Company ABC wants to ensure that all Salesforce users can run Salesforce reports.

• Company ABC needs block Salesforce reports that access over a set percentage threshold of total Account records by RecordType.

• Example: 

  • The Account object has 3 recordtypes (Distributor, Wholesaler, Retailer)    - The Account object has a total of 360 records.    - 10 records are assigend to the Distributor recordtype    - 50 records are assigned to the Wholesaler recordtype    - 300 records are assigned to the Retailer recordtype

• Company ABC has a policy that no Salesforce user can access more than 50% of Account records for a given recordtype.

  • Ted is blocked from running an Account report accessing all Distributor Account records.
  • Frank is blocked from running an Account report accessing 30 Wholesaler Account records.
  • Jen is not blocked from running an Account report accessing 150 Retailer Account records.

Would Salesforce Shield Event Monitoring (specifically Transaction Security Policy) solve this problem? Or are there alternative solutions that may solve this problem?

I appreciate any help offered. ​​​​​​​Thank you.

Answer 1

So, yes - the relevant SFDC tool is Shield Event Monitoring and Transaction Security Policies. Report Events can be monitored. This includes both report viewing and report export

HOWEVER, the ReportEvent object buries the details of the report's rows within the Records field as a JSON string:

A JSON string that represents the report’s data. 
For example, {"totalSize":1,"rows":[{"datacells":["005B0000001vURv","001B000000fewai"]}]}.

So, you would need to write an Apex Transaction Security Policy that would be aware of the specific reports or sobject to monitor, and some sort of parser that would inspect the Records field for Ids that looked like recordtypeIds (or Strings that looked like recordtypeNames).

This could run into Heap issues for large reports.

If the recordtypeId (or recordtypename) were not part of the report columns you'd have to exploit the report's Account.Name (or Id, autonumber or other unique external id) to query for the recordtypeIds. This could run into limits issues with > 50,000 report rows

Your business problem could be handled with OOTB point-and-click TSP config if you relaxed the recordtype requirement as row counts versus users can easily be configured.