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 😛 … 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 🙂
Best Answer
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!!).