Yes! Skuid supports querying, writing, updating, and deleting both List and Hierarchy Custom Settings. You can work with Custom Settings from within Skuid just like you would any other SObject Type. There are some differences, of course, between working with Custom Settings and regular SObjects, that you’ll want to keep in mind when building Skuid Pages around Custom Settings. List Custom Settings work basically like regular SObjects, but Hierarchy Custom Settings are a little strange — since each Hierarchy Custom Setting has to be associated with a Location, such as the global Organization Default, a Profile, or a User, you’ll need to include the “Location”/SetupOwnerId field in your Model and in your Table. You might want to add a Condition on your Model to not show the Organization Default (a condition on SetupOwnerId), and require that this be set through Setup > Develop > Custom Settings.

(Note: answer updated as of 4/11/2013 8:54 PM EDT)

it would be nice to use them to store user information… like the last record a user was looking at etc… but i’m reluctant to use them if the users can’t write back to them. I guess I could make regular visualforce pages to update them if i used them to store lists of cities and states and stuff like that.

Users should be able to write back to Custom Settings using Skuid, such as a Hierarchy Custom Setting for storing user preferences, like the last record a user viewed. That’s actually a very interesting example — for instance, you could have 2 Models in your pages, one on the Account object, pulling in just a particular record, and then your Custom Setting object, which just pulls in (or creates, if it doesn’t exist) a Custom Setting record for the running user. Then, on that record, you could have a Model Merge condition which populates a field such as “Last_Account_Record_Viewed__c” with the Id of the record in your Account Model. Then you’d just need to have a line of JavaScript that gets run as soon as the page is loaded, which goes and updates/inserts this Custom Setting record, so that you’re constantly updating the Id of the Last Account Record the user viewed every time that the user views an Account. That line of JavaScript should be stored in an “Inline” JavaScript resource, and it’s body would just be this, assuming that your Account model is called “AccountData”:

$j().ready(function(){ skuid.model.getModel('AccountData').save(); }); 

Regarding storing lists of cities and states, I would absolutely use a List Custom Setting for each of these.

Zach … re your point early in this thread about hierarchy custom settings. I have a hierarchy custom setting with one record in it for each of our standard profiles. I have a model based on that custom setting and I include the Location field in it. So when I run that Skuid page, should it automatically just return the record in the custom setting that relates to the running user’s profile? In my testing just now, it always returns all of the records. Am I missing something?

No, you’ll have to specify via Conditions on the SetupOwnerId field which Custom Setting record to retrieve. If you only ever care about a Profile setting, and you’re guaranteed that it already exists, this will be easy: just have one Condition on your Model like this: SetupOwnerId = (userinfo) Profile Id However, if you’re trying to replicate the hierarchy retrieval functionality you’d get via Apex, that is, to look first for a User setting, then for a Profile setting, you should have have 2 Conditions like this: 1. SetupOwnerId = (userinfo) User Id 2. SetupOwnerId = (userinfo) Profile Id with OR Condition Logic: “1 OR 2” Then you’ll need to Order your query by SetupOwnerId and have a Limit of 1, which should guarantee that you always retrieve just 1 setting at the most specific level possible. This works because user records start with 005, Profiles start with 00e. If you want to have Organization Id as a final fall-back, you may need to have multiple Models and use Field from another Model conditions to achieve the User, then Profile, then Organization hierarchy, because unfortunately the Organization record starts with 00D, which throws off the hierarchy alphabetical sorting.

Hey Zach … We’re just now getting into implementing this now. I get the way you’re handling user and profile level records and how ordering and limit 1 will do the hierarchical trick there. But I need to have the organization level record as a fallback for sure, and I can’t work out how to do it. Not sure what you mean by “If you want to have Organization Id as a final fall-back, you may need to have multiple Models and use Field from another Model conditions”. Could you fill me in a little more there perhaps? Thanks.

You know, I’m not sure how I thought that this would be possible — I’ve tried everything I can think of with multiple Models and no approach seems to be able to avoid the same problem that exists with the single Model approach I listed above.

OK, I’ll come up with a plan B. Shame we can’t have a formula field on a custom setting. We could put a custom Order field on the custom setting, but that’s a bit manual. Hmmm.

Hello all - I am trying to query a list custom setting in my system called “OrganizationalBudget”. When I try to find this custom setting to create a new model with it, all I can find are the associated tags:
Do you know if there’s something special I need to do to be able to query this custom setting?


Thanks!

Aparna

Aparna, the List Custom Setting must be marked as “Public” in order for it to be visible to Skuid — if it is marked “Protected” then you can’t interact with it via Skuid.

Thank you, that helped fix this!