We’ve noticed a delay of around 2 to 3 seconds when viewing a Skuid page via a Salesforce Community, that doesn’t occur when the same Skuid page is viewed directly in Salesforce. The delay occurred on page load and apparently after some model refreshes. We are accessing the Skuid page directly, not via a VisualForce page.
In the browser console I get this message repeated 10 times immediately after the delay in loading occurs:
[Error] Failed to load resource: the server responded with a status of 500 (Internal Server Error) (31.0, line 0) https://[customdomain].force.com/services/Soap/u/31.0
Note that error path doesn’t include our community name, so I wouldn’t have thought the community user would have access to it. When I add the community name to the path I get error 405 “GET not supported”.
I’ve spent a while trying to isolate the cause, and what I’ve found is that if I include any picklist field from a model into a table or field editor component, the error/delay then occurs. Remove the picklist field from the component and it goes away. I haven’t seen the problem with other data types. Maybe it’s happening when loading pickiest value meta data? But the values are available in the picklists.
For example, create a page for the Case object using the List template. Load it in communities and it goes fine. Then add the standard Origin field to the table component. Refresh the Skuid page in the community and you get the delay and console errors described above.
Performance issue when displaying picklists in Salesforce Communities
+4
+13Ryan,
A couple of questions, and a couple of thoughts:
Questions:
- What Skuid version are you running?
- Do your Community Profiles have API Access enabled?
- Can you Grant Login Access so we can review this?
Thoughts:
- The reason picklists cause this delay is that for Picklist/Multipicklist fields on objects with Record Types, Skuid has to make a call to the Salesforce API in order to determine which Picklist values to display for a given Record Type. Unfortunately this information is not available natively in Apex, so we have to make this separate call to the API in order to retrieve this information. See these ideas on Salesforce IdeaExchange (and vote them up if you agree that this is ridiculous that we don’t have access to this metadata in Apex): https://success.salesforce.com/ideaView?id=08730000000l5SnAAI and https://success.salesforce.com/ideaView?id=08730000000BpHAAA0 In order for Skuid to access the API to do this though, your users will need to have API Access enabled.
- There may be a bug with your version of Skuid related to a Community prefix not being prepended to the call to the API, but the fact that you got a “405 GET Not supported” error when prepending the Community prefix makes me think that there may be another issue going on here, so we would like to take a look at this happening in your org to get a sense of what’s going wrong.
+4Hi Zach,
We are running version 7.12. No trouble to upgrade if that will help.
Yes, the profile has “API Enabled” as true. It is on the “Customer Community Plus” license.
Agree that is a silly restriction around picklist options and Record Types needing an API call. It’s interesting that Skuid displays options anyway, perhaps that’s a fallback without taking Record Type into account? Also that it tries to hit the API 10 times, if it was only once it probably wouldn’t have the same performance hit. I wonder if it relates to the number of records in my table.
I’ll be in touch about access, it might be a bit early in our project for that yet.
Cheers,
Ryan
+13Ryan, your point about it trying 10 times being related to the number of records in your table is a good one, we’ll take a look at that to see what the logic is as far as us trying again after failures.
+4It appears that the number of retries does relate to row count. When I change the number of Cases shown in the table from 10 to 5 I only get the message 5 times.
We do indeed have record types on our Case object.
I’ve updated to 7.19, the issue still occurs. Doesn’t look like the community prefix is in the API call.
+4Because the picklists are all read-only on my page, I’ve been able to implement a workaround. Just used a custom renderer which renders those fields as text. No more delays and that message is gone from the console.
+7This issue is affecting me as well. I have updated to 7.20 but the issue still occurs. Does anyone knows why this is happening now?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.