Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
ToreTore 

Custom Objects/Date Storage

From what I understand it is not possible to add custom objects or even add new fields to existing objects via the api at this point.  I would like to store small amounts of data relating to the user's setting (in this case storing usernames and passwords for yet other applications as well as mapping Salesforce fields to fields in these other applications) within salesforce rather than our own additional database to store this data. 

Has anyone come up with a useful way to store this kind of information?  I thought about making a custom S-control to store this information in (which could be formatted in such a way it could be displayed usefully to the user) but that seems hacky at best.  Should I just forget it and build my own database and wait for the update to the API?  Has the API already been updated and I'm just not aware of it?  Are there any other ideas?
DevAngelDevAngel
I suppose you could create three custom fields on the user object.  One for username, one for password and one for the relevent application.  Then, you can just get the user name and password based on the relevant application as a key.
ToreTore
I wouldn't be able to create these fields through the API though right?  The idea is that the application can install itself, but if these fields would have to be made manually then I guess I would opt for an external database.
DevAngelDevAngel
Security issues aside, you could create a custom object that is related to a user object.  The custom object could then contain the data you need.

I have reservations about storing authentication information in the clear in a salesforce account.  Anyone with read all permissions would be able to see the info.  If you are going to encrypt it before putting it salesforce, then that's cool.
ToreTore
From what I saw in the API documentation it's not possible to create a custom object (via the API).  This is really the important thing, if this is possible can you point me in the right direction? I'm totally with you on the password issue as well.  Thank for your help.
DevAngelDevAngel
Right, ok.  The metadata API as represented by the describeX calls are read only.  This means that you cannot create or modify meta data in the current API.

Read/write meta data APIs are in the works.

Sorry for taking the long way around this one.  Of course, if you put your app into the AppExchange, the custom objects you need would be installed by the customer when they install your app.  So you would basically have an AppExchange app that configured the salesforce.com data model and a client or server side piece that contains your standalone code.  If you create and installer, then you could put that in a document to be delivered with your data model changes allowing you to deploy the entire solution through the AppExchange.

Cheers
SteveBowerSteveBower
DevAngel, every now and then you, or one of the other Salesforce guys will drop a bon mot like:

"Read/write meta data APIs are in the works."

Can poor slobs like us (meaning me, unaffiliated contractors who don't get briefed by a salesman) get a glimpse into the roadmap? After all, this is a pretty substantial addition and could easily color the way we might develop some bit of functionality today.

It makes me wonder what else is on the docket.  Can we get a view into that information while promising not to hold you accountable for it?

Thanks, Steve Bower.
DevAngelDevAngel
I don't know what a bon mot is, but I'll assume it's not a put down!

I would love to give you a peek at the roadmap.  Alas, you might not hold me to it, but every other Tom, Dick and Harry will.  I will see if there is a forum in which this can be done.  Might involve document signing or some other lawerly thing.
SteveBowerSteveBower

Hi Dave, I'd be happy to sign something saying I won't hold anybody to any promises. (I like the idea of a feature oriented "safe harbor" sort of document! )

Thanks Steve.

Bon Mot == Good word.  Usage is typically for something particularly witty or clever.