+ Start a Discussion

Apex Question

Force community,


I've been reading up on license types, and realized that a new feature I'm trying to add is not going to work. Currently, my Site displays customized user information based off of their Contact ID, and then uses that information to authenticate through the various pages of the site, viewing records assocaited with their account. 

Its working pretty well, but the problem is that they are seen by Salesforce as Guest License users, and are unable to Update the Contact object. I'd like people to be able to input a new email address, billing address, etc, so that my clients can imrpove my database's integrity, without my team having to do so all the time.


What is the best way to update the contact field's I'd like to user to change? A webform, with a workflow on my organization? Some other manner? 


Any help is appriciated!


You can't do this I'm afraid - even if you try to use workflow, triggers or asynchronous calls, the license type of the user that cause the chain of events to happen is taken into account and you will get an error.  The way I've handled this before is to allow the users to create and update a custom object associated with their contact, and then provide a button on that object that an internal user clicks to update the parent contact.  Its not ideal but does work.


Adding to what Bob has said, from public sites we only have Create and View access to all the standard objects. So to have the users to edit or delete we need an intermediate wrapper class to perform the edit and delete functionality.





I appreciate both of your comments, but I'd like to run my latest idea past both of you:


A Custom object, called "Portal User", has a couple of fields, the most important of which are PortalUsername and PortalPassword. I was thinking I could create a Visualforce page with Apex trigger that would display the two fields, and allow updates to the custom object. 


At that point, I would create a workflow, field update, trigger , or whatever in our Salesforce system, that would push an updated "Portal User" to the contact object, which also has "Username" and "Password" fields.


My end goal is to update the Username and Password fields on the Contact object - this Contact authentication is what I have built my entire system around, from record lookups, logins, etc. 


I could see there not being default support, but there has to be a way to update the Contact object from a Guest Site User License through an intermediary object, trigger, workflow, web service, etc.


Hate to tell you this, but I'm pretty sure rolling your own authentication is a breach of the Salesforce license.


Hmm, well thats a bit of a wrench in the system eh? 


The reason I started building the page was because I thought it was not possible to open certain custom objects to the Customer Portal, so I tried to display records through a Force.com Site. 


Back to the drawing board on how I call records, I suppose. 


Thanks for the heads up! 


You should be able to open all custom objects to the customer portal - its standard ones that can cause the headache.


If you have a lot of users there's the high volume portal license which is more cost effective.


Sorry, thats what I meant to convey. 


Now I'm going to rework the pages and always wonder wether its possible to do what I proposed. Oh well, some things arent always worth the development time just to 'find out'. 


Thanks for all of your input


A new thought - Say I have an existing customer portal outside of Salesforce entirely.


What can I do to display records from the Org inside my portal? Do I need to buy an authenticated license just to display an iFrame of the user's data, etc? Is there a better way to pull bits of data related to a client, without using the entire Customer Portal environment?


If you access the data via the API then one license should be sufficient.  If you are iframing it in, I think you'd probably still need a license per user. Just remember I am not a lawyer!




Thanks for the input. I've been thinking over the weekend, and its a little frustrating to have to conform to the license models and 'walls' inherent in the SFDC archtiecture. 


Obviously its part of their ecosystem, and you have to play by their rules if you want in, but it doesn't make much sense for a Business-to-client Customer Portal to exist inside the Force.com Sites/Visualforce area. Its simply too expensive. I'd save myself a boatload of money in a year not paying $15/month licenses if I just sync'd to an external database on AWS, and displayed the information there through my own portal.


I understand businesses are out there to make money, and so is mine. But the pricing structures for these licenses make it nearly impossible for B2C, and I'd imagine 'tough' even for B2Business, if you aren't very large or established. 


Licenses shouldn't cost you that much - you can get high volume portal licenses which are aimed at B2C from around $0.50/month.  


I must have missed that in the confusing (at least to me) license types page. I've read it 10 times and don't totally understand the differences. 


Any idea of the minimum quanity I have to get for High Volume users, to get anything under a dollar/month? Totally unofficial price guestimation, of course :-) 


I've seen pricing for authenticated sites user license that start around $1500 per year for 100 named users.  There's also pricing based on logins/month, which has a higher entry point (5000 logins per month) and was around $7500 per year.    I'm not sure there's a rack rate for this though - these licenses have to be approved for sale and the pricing is worked out on a case by case basis.



Ken KoellnerKen Koellner

What I found is that a VF controller without sharing can update any record.  But if you put the record directly on the page and it has an "ID", the fields won't be writable.


So if you want to do an update, there's two work arounds--


  1. Use input tags on your page not associated with the existing object.  Then in your safe method in your controller, put the values in the sObject  you want to update.
  2. Cache the ID of the object(s) somewhere else, set it to null in the object, then during the save, replace the Id with the cached ID.


See this thread for details -- http://boards.developerforce.com/t5/Force-com-Sites-Site-com/Site-written-in-VF-and-access-to-standard-objects-with-Public/td-p/700949