from a post on a salesforce board “There is a limit that in a single context run you can have only 100 fielddescribe calls.This is one of the governor limits of platforms” is there a loop in the custom object “Application”, and does it make “getDescribe” calls ?

We’ll start by describing what causes this, then propose a workaround. Cause: Skuid uses Apex to retrieve metadata for Picklist fields, specifically the values in those Picklist fields. In general this is the best way to retrieve this, otherwise we’d have to burn through API calls, which is non-ideal for many reasons. However, Salesforce imposes a (frustrating) Governor Limit that within a single Apex execution context/transaction — e.g. when a Skuid Page initially loads — you can only retrieve metadata for 100 unique Picklist fields. These fields can be distributed across multiple objects, and you can include a unique field in multiple Models on your Skuid Page, but within a single Apex execution context/transaction, you are limited to retrieving metadata for 100 unique Picklist fields. Workaround: In general, the only way to avoid this limit is to split your single execution transaction into multiple transactions. The easiest and most effective way to do this within Skuid, and a way that is often very useful for other reasons as well, is to make use of Skuid’s “Page Include” Component. The basic idea is to extract out areas of your page, for instance, the contents of one or more of the tabs in a tab set, into separate “child” Skuid Pages, and then to “include” these in your “parent” Skuid Page using the Page Include component. The reason that this is helpful for your situation is that each Page Include component runs in a separate execution context — so the Governor Limits are reset. So, for example, if you had a “Personal Information” tab that had 30 picklist fields in it, you could extract the contents of that Personal Information tab into a separate Skuid Page — models and components. So, where currently you might have a Contact model with 100 fields on it, in your “child” page you would again have a model on the Contact object — but call it something like “ContactModel_PersonalInformation”. ContactModel_PersonalInformation would contain only the 30 fields you need for Personal Information. Then you can remove these fields from your parent page’s Contact model. That way you decrease the number of unique picklist fields referenced in your parent page, offloading the work to the Personal Information child page. This of course you could do for as many of your tabs as you needed. The Tab Set component is actually a great place to introduce this paradigm, because there is an option on Tabs called "Load Lazy Include Panels when Tabs are clicked " or something like that, and a corresponding option on Page Includes called “Lazy Load”. If you have these options turned on, then what happens is this: Skuid does not load the “Lazy Load” Page Include components when the page initially loads — these Page Includes expect to be “lazy-loaded”. They don’t get loaded until the user first clicks on / goes to the tab that contains them. Why is this good? Well, for several reasons: 1. it makes your page initially load faster because the page doesn’t have to render certain areas until they’re actually needed 2. your models that are not in page includes will load faster initially because they have fewer fields in them, and thus less data and metadata has to be retrieved 3. this makes it easier to manage the content of certain tabs — you could, in fact, “delegate” administration of the pages contained in these tabs to other users, allowing them to edit those child pages, but not the parent page. 4. it gets you around the 100 picklist describes governor limit Using the Page Include component is pretty straightforward, but here is a tutorial to get you started — you will be using the “Skuid Page” type of Page Include: Tutorial: using the page include component

Great solution on many levels. Thanks.