So, I've been given the task of writing a web application for constructing and submitting quotes for my company.

First off, I'm brand new to SalesForce, and I'm understanding it better and better every day, however I'm still fairly uncomfortable with what I need to do here. I do know that the REST API is what I want to use for this.

Now, I've gone through this REST/PHP example and what confuses me is, after authentication, I'm brought to the actual login page for SalesForce. From what I've read, this is my question - do I have to login with this just once in order to verify my webapp with the SalesForce application, and from here on out, I can just connect directly without having to actually login to SalesForce? That's kind of the gist I'm getting from some of the comments and forum posts I've read, but I'm not sure about that.

Next question is this. What is the best overall approach for what I want to do? Like I said, I'm new to SalesForce, and I'm getting a lot of pressure to get this app done. I don't have the time, unfortunately, at this juncture to read all the docs and write a bunch of test apps.

The application sounds simple, but as I'm getting more into this, I'm fearing this may end up being a bit more of a project than we originally anticipated.

The application is to be housed on our companies servers, and written in PHP. The idea is to allow specified customers to login to our application based on a custom field we've added to hold their password. They should remain completely on our server, and all data they see from SalesForce should solely be pulled using the REST API. So our app should, ideally, login to SF behind the scenes - server to server. When the user inputs their creds, it will pull them from the SF database, and check the validity. Once they are inside the application, they are presented with a sort of "step-by-step" product build process which uses the metrics of the pricing matrix in the SF database. After they finish their product build, they should then be able to submit it to the opportunities table in such a way that it will be assigned to the actual sales rep to whom that particular client has been assigned.

There are some other interesting problems as well. Some of the items in the pricing matrix are only compatible with certain others, which is currently being handled by the sales reps who actually know which is which and what 'set' of items can go together in any one particular formation. Is there a way to handle this with SalesForce or am I going to have to handle such logic in my app?

My main question is - how do I handle this in the best possible way? As in, what SF technologies do I need to use, and what specific aspects of each technology will I most likely be using? I'm just looking for broad suggestions.

Also - and I guess this would be important :P ... is this even possible, or are we barking up the wrong tree?

and as a side note: we've already cleared this with SalesForce, as far as TOS goes, there are no problems on that front.

Thanks all :)

1 Answer 1


Well, my first comment is that custom authentication is outside the TOS, but it sounds like you've got that covered. Kind of surprised they didn't pitch you on what a great investment those customer portal licenses, ahem, sorry, community license are.

Since you're program is talking to Salesforce on behalf of non-Users, you'll want to have a single API only user that your program uses to authenticate and make the appropriate data model changes in Salesforce. This is pretty common for integrations, and also programs that handle their own authentication for non-salesforce users. Some tips for designing this.

Use the username/password oauth flow

Used to be you'd use the SOAP API which is setup for username / password flows for this sort of thing, but the REST API is new and awesome, and needs OAuth. Since it doesn't make sense for your application to get authorized by a user (since it's a privileged application) use this oauth flow to skip that part.

Of course, there is always the SOAP API, which has PHP toolkits, bulk data support, and a lot longer history, and hence better community and support. This is changing rapidly, since REST is awesome!!

Use an API Only User

Heaven forbid someone gets access to the username / password for the API user, they won't be able to login and poke around (of course still a lot of damage to do there). API only is an option for the user's profile.

No Password Expiration Profile

Give the API user's profile no password expiration so your program doesn't spontaneously crap out.

Turn off ALL objects not needed by the application

The API user is going to need view all / modify all perms in a lot of places. Limit your exposure of this by making sure they only see just as many objects and fields as it needs to perform the quote.

Security is in your own hands (IMPORTANT)

Since you're rolling your own authentication all responsibility for making sure one user doesn't mess up someone elses data is on you. Make sure to devote extra time and resources to this.

Hide those credentials

One mistake to avoid. Store those credentials away out of your code. Nothing is worse than seeing a username and password listed in someones source control (please use source control!!).

  • This is perfect. Thanks for the answer. I do have one lingering question - how would you approach the dynamic relationships of the items in the pricing matrix. ie: Item 1 is only compatible with item 33 and 78, and item 5 can only be bundled with item 98 so long as item 57 has already been added. Can I do this SF-side? Or is this something I'll have to hack up? Thanks :) Commented Nov 4, 2013 at 17:49
  • 2
    Great question, can you ask it in another thread? That way someone down the line can benefit ;) Commented Nov 4, 2013 at 18:13
  • I think this is a great breakdown on how to proceed, but I'm having trouble with the OAuth flow...when I try to login using a REST API call (POST), I'm getting Access-Control-Origin errors. Do you recommend enabling CORS on the Salesforce side? Or do you know of a better way to circumvent this issue?
    – jlewkovich
    Commented Jul 27, 2015 at 20:52
  • @JLewkovich that's a great question, i haven't come across it personally. Since that's pretty particular and relevant in it's own right, can you post as it's own question? that'll get a lot more attention than a comment here ;) Commented Jul 29, 2015 at 14:02
  • @RalphCallaway I've opened my issue as a separate question here: salesforce.stackexchange.com/questions/85349/…
    – jlewkovich
    Commented Jul 29, 2015 at 15:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .