function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
anagramanagram 

Where to store S-Control setup/preferences data?

Hi- Apologies if this is a basic question but I'm developing an S-Control and am looking for the best way to store some simple preferences data for the s-control. There will be an html user interface with some checkboxes and radio buttons and I'd like to store the user's preferences somewhere in the user's profile and be able to recall the settings inside the S-Control.

There must be an easy way to do this but I just can't find any info anywhere!

Thanks!
Nicholas


Greg HGreg H
I've done this a couple of ways.  You could create custom fields on your user records to store the preferences. But this will actually make those preferences visible to the user when they look at their own user record - and thus may not be a good idea depending on what you're storing.  The option I almost always use is storing the preferences as a record in a custom object.  You can create a recordtype specific to your preferences records and use the Id of the user as a custom value so the retrieval of that data will be easier.
-greg
anagramanagram
Thanks for the ideas Greg! I had thought of the custom object solution but I figured there must be a more appropriate way to do this. Seems odd that this functionality would be lacking from the Salesforce api.

I will likely use the custom object method unless someone knows of a better way!

Cheers,
Nicholas
sfdcfoxsfdcfox
My two cents on this...

Custom objects are great this way. Imagine a custom object with reporting disabled, no tab, no lookup relationships to any other object, and a blank layout. The user would never know the object exists (unless they're toying with the Excel Connector or Data Loader, or the Setup screens), and yet it would be able to save/load their preferences directly through the API. It's clean, tucked away, and very easy to use and customize. I actually thought of doing something like this for other stuff I've played with in Salesforce (for example, a "password manager" object for single-sign-on to other web services), and it makes sense. Uses virtually no storage space (2kb per user), can hold a large amount of configuration data, and loads in a fraction of a second in most cases when using the latest AJAX toolkit. You could make it even better these days with an Apex Code web services call (web services calls currently ignore security), which means you could make it completely invisible to the user unless they knew how to access the web service directly-- you could hide the entire object!
anagramanagram
Hmm, you bring up some great points. I guess it's not such a bad way to go afterall.

Thanks!
Nicholas