I believe you could do this with the meta-data API, but why not use a lookup relationship? Then the agent could simply click on another tab to add a value and it would immediately show up.
If you can't modify the field in Setup, you can't use the meta-data API, as you'll just get a security error. However, most picklists will accept values not in the list for a record by supplying the value via the API. For example:
Code:
myRecord = new sforce.SObject("Lead")
myRecord["Id"] = "{!Lead.Id}"
myRecord["My_Picklist__c"] = "Some Value Not In List"
sforce.connection.update([myRecord])
Ooops, sorry, I misread your question as being about 'access to' the setup area rather than edit access.
I am curious about your use case, though. Typically, pick lists are used both for user interface and to limit values to protect data integrity. Are you going to give some users the ability to dynamically add values to a pick list, which would then be there for other users? If so, I would still think a related object would work out better.
Please let us know - I am always looking for use cases that call for exceptional implementation.
I needed this only because our marketing team is adding values to our lead source pick-list every week and sometimes I'm not here and don't want to give them admin access.
But otherwise I complete agree with you about creating a related object.
Also, keep in mind that the values that Marketing adds to the picklist will not show up in the drop down picklist automatically. They will be marked as inactive, so they will not appear. Sounds like there could be even more integrity problems, with multiple Marketing folk adding similar values for the picklist.
This probably doesn't help the problem, but might help you with figuring a better solution.
Hope this helps.
I am curious about your use case, though. Typically, pick lists are used both for user interface and to limit values to protect data integrity. Are you going to give some users the ability to dynamically add values to a pick list, which would then be there for other users? If so, I would still think a related object would work out better.
Please let us know - I am always looking for use cases that call for exceptional implementation.
But otherwise I complete agree with you about creating a related object.
Thanks for the explanation.
This probably doesn't help the problem, but might help you with figuring a better solution.