Salesforce Implementation Restriction on ActivityHistories

  • 1
  • Question
  • Updated 2 years ago
  • Answered
Hi,

All our contracts store an activity when an email is sent to a client. Using this tutorial (http://help.skuid.com/m/models-conditions-filters/l/102520-include-child-relationships) I was able to create a Skuid page as required. My issue now is that non Salesforce Admin users receive the following error message:

"There is an implementation restriction on ActivityHistories. When you query this relationship, security evaluation is implemented for users who don't have administrator permissions, and only a single parent record may be evaluated. 

An unexpected error has occurred. Your solution provider has been notified. (skuid)"

I found an explanation on the forum which makes sense:

"This is actually a fairly common error message, and you'll encounter it in weird places on various Standard objects. It only ever happens for non-Admin users, because non-Admin users' access to records is governed by the Salesforce Security Model, whereas Admins have the "View All Data" permission, which means that Salesforce ignores the Security Model completely for them when choosing which records to let Admins access. So for Salesforce's purposes, it's a lot more "expensive" to try to determine which records a non-Admin user should have access to, because Salesforce has to evaluate the whole Sharing Model for a given object when a non-Admin user runs a query on that object. Therefore Salesforce puts in these "Implementation Restrictions" that limit how many records of these Standard Objects that non-Admin users can request in a particular transaction. This makes sense for standard Objects like Task and Event for which there are often millions of records in customers' orgs, because Salesforce's Query Optimizers have to do a lot more work to try to search through these millions of records trying to find ones that a non-Admin user has access to."

What solutions are people using to avoid the error message caused by Salesforce limitations?

Regards,

Damien
Photo of Damien Murray

Damien Murray

  • 474 Points 250 badge 2x thumb

Posted 2 years ago

  • 1
Photo of Emily Davis

Emily Davis, Employee

  • 3,502 Points 3k badge 2x thumb
Hey, Damien,

A few questions:
1. Are you using a list of parent records (e.g. a list of Contracts, getting the Activities for each Contract)? Or just a single parent record? It sounds like this issue may be coming from pulling in child records for multiple parent records.
2. How are you displaying information on the child records (a screenshot might be helpful here)? In a Template field on a field editor or table? Or in a separate component (like a table drawer or popup)?


One idea to avoid these errors is to use a separate model on ActivityHistory, rather than the child relationship on the Contracts model. If using a list of parent records, display these activities in a drawer or popup. This tutorial gives a good example where we only query for specific child records when we need them: http://help.skuid.com/m/supercharge-your-ui/l/269735-add-nested-rows-to-your-table-with-drawers




If you choose to go the child relationship route, it may also help to add some limits to your child relationship (if you haven’t already done this). To set these, click on the child relationship in the list of model fields, and go to "Conditions" and "Properties".
1. Limit the number of records
2. Add a limit to your child relationship (e.g. 100) 
3. Specify an order (e.g. ActivityDate ASC, or LastModifiedDate DESC to see the most recent)



Also, a hint: You may run into issues trying to use the ActivityHistory object in Skuid, since there are some Salesforce API limitations around this. If this happens, you may have to create 2 separate models,ClosedTasks (Task records where IsClosed = true) and ClosedEvents (I think this is Event records where StartDateTime < TODAY).



Emily
Photo of Damien Murray

Damien Murray

  • 474 Points 250 badge 2x thumb
Hello Emily,

To close this one off, we enabled the view all data button on the non-Admin profile which resolved the issue. Fortunately the profile doesn't need to be restricted from viewing data so it was a workable solution for us.

Cheers

Damien