We have 3 models, 2 are aggregate for use with Charting and the third is a basic chart for pulling specific report related data. We have a Tab Set and use the Picklist function. The two charts draw pretty much immediately, but the table takes about 30 seconds to display. It is obviously using a selection criteria that returns 66 records from a thousand or so. The we have a filter that allows the user to filter by Category. If you change the filter is takes a minimum of 50-60 seconds to re-display the information. I know that using the aggregate model will allow SF to do the processing and basic brings the record set down to the end user, but this is quite un-usable. Can you have an aggregate model and still bring fields into the table that are not defined as aggregations?
Speed Up Table Filters
+5
+17- Nintex Employee
It sounds like your query performance is suffering. I’d use this document from Salesforce to look at ways your SOQL query might be improved. You might also contact Salesforce and ask that additional fields on your object be indexed to increase performance.
+5I’m not thinking that is the problem considering the number of documents being returned, a subset of 68 out of about 6800 and SF performance indexing performance really becomes an issue when you hit much higher thresholds. In Chrome, I am see the “Transferring data from …” which takes forever when using a SKUID table but when I load the same SF report with the same filters and data, it takes literally 2-3 seconds.
+17- Nintex Employee
Here is a test. In your skuid page open the browser console. Type the following javascript command.
skuid.$M(‘YourModelName’).soql
This will give you the actual soql that skuid is running.
Then open the salesforce developer console and run that query in the query editor.
If there are substantial differences in performance we’d like to know about it. If both queries take a long time its a problem at salesforce. Standard layouts and reports use substantially different technologies (smoke and mirrors) to present data quickly. They are not reliable comparisons. Though I do wish we could leverage them in some way…
+5When I refresh the page, it takes about 240 seconds to get the following, and 200 records are displayed. If I click the “Load More” button, it takes about that long.
The following is what I get from the Browser Console:
“SELECT RecordTypeId,RecordType.Name,Category__c,Sub_Category__c,Service__r.Name,CaseNumber,Closure_Status__c,Closure_SubStatus__c,Resolution_2015__c,Description,Id FROM Case WHERE (Service__r.Use_in_Reports__c = true)AND(ClientNum__c = ‘XXXXX’) LIMIT 10000”
When I put that in the developer console in SF, I get back the results in 2 seconds and it returns 994 records.
+17- Nintex Employee
Would you mind giving us login rights to your org so we can take a look at what is going on? Here is how:
1. Use this tutorial to give us login rights: http://help.skuidify.com/m/getting-started/l/182412-getting-help-how-to-grant-skuid-login-rights-to-…
2. Then send an email to support@skuidify.com with the following information:
- Your org Id
- The name of the page where the problem is happening
- The steps required to reproduce the problem.
We’ll see what’s going on…
+17- Nintex Employee
Here is some further information from Ben: (Sent via email)
Well I am not quite sure what is going on but I had the table set to “Apply Filters and Search Immediatley” to false. When you bring up the page, and select the Cases table nothing shows. That most certainly is quick. I set that value to True, and when in the page designer, Preview, the table is almost instantaneous. When logged into our Community Site and access the page via a tab, it takes 2 minutes to load the data, each time you select the tab or a filter.Why would there be large differences in load time between an admin “previewing” a skuid page, and a community user viewing the same page. Sharing rules. The admin has a “view all records” permission and therefore Salesforce does not need to evaluate sharing rules for each record. But when the community user asks for the data, Salesforce has to evaluate the sharing rules on each record.
So, this makes it even more critical to reduce the number of records requested in the model, and base conditions on indexed fields.
+5Still not convinced. Although the whole Admin theory seems to make sense, we have done a ton of testing and really don’t think it has anything to do with the Sharing and how long it takes SF to serve up the records. We have 2 visualizations that use similar selection criteria and are accessed via a community user and the data is returned immediately. We have reports that the data is returned immediately, and we have standard SF views that are returned immediately. We even went so far as to add a new text field designated as an External UID which will then get indexed by default by SF and made that the only field in the selection on the Model, same performance. We use another product for Grids/Tables and when creating and viewing them, the data is instantaneous. Wasted way too much time on this but if this is not about how our page is setup, and I am assuming it is not based on the above, and we have a single condition in the model and this is the type of performance, then using a table in communities is simply not an option due to the performance.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.