Tell me more ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.
up vote 6 down vote favorite

I'm working with a client to develop a PHP based application that has its own login system and content but throughout the application there will be interactive forms which will collect data that we'd love to have save back to salesforce contacts and custom objects through the api.

My question is that is it ok to do that with the rules of the API all through one system admin user or do the systems users all need have their own salesforce user accounts?

share|improve this question
Thanks for the comments so far. My specific app is going to have users who will be creating contact records, and the app is a collection of interactive forms which will collect even more information about those contacts, some of that data will go on custom object, some will save right back to the contact record. So in some ways its similar to a mass email tool that creates contacts and stores information about emails sent to them (which I know all use one api user) but they are creating contacts which i guess they own, so? – Keith Mancuso Aug 15 '12 at 14:58
Have you thought about using OAuth in your PHP app to obtain a token specific to the user? It seems to me that this would avoid any license ambiguity and remove any need for your PHP app to do any of its own ownership/sharing validation. See this article for a rudimentary example; you can use the same OAuth access token with the SOAP API as well as REST. – metadaddy♦ Aug 20 '12 at 21:50

3 Answers

up vote 8 down vote

I think this largely depends on how you frame the situation. If it's simply an integration between two systems then it's common practice to have an integration user in Salesforce to represent the remote system.

However, if the PHP application is more of a front end for Salesforce used by multiple users, who individually 'own' data records, then you should be using a licence per user, as all you're really doing is creating your own user authentication layer above the platform which is not allowed according to the T&Cs.

Update If the users own contacts as you say, then I'm afraid you're falling on the side of needed licences for each user. If they contacts are shared and visible to all, without being tied to particular users then you could just use the one licence, but it sounds like you'd still be toeing the line in this scenario.

share|improve this answer
3  
This is correct - we've butted up against this several times as a Salesforce Partner. As a rule of thumb, if you're not using the external authentication to bypass paying for Salesforce licenses, you're in the clear. – James Davies Aug 15 '12 at 3:56
That all makes sense, but I think my app is still in a little bit of a gray area. – Keith Mancuso Aug 15 '12 at 14:55
up vote 3 down vote

The main consideration is if your architecture is (or can reasonably be perceived to be) designed primarily to circumvent salesforce licensing. One question to ask is whether you are re-creating any of the core functionality of salesforce in your app. For example, using a single integration user means you lose visibility on the back-end into who added or changed a record. If you create fields in your custom objects to keep track of these things and integrate it into your PHP app's user management system, it could reasonably be concluded that you are doing this to get around licensing each user, even though you desire some of the functionality that licensing them would give you.

share|improve this answer
up vote 0 down vote

You should also watch out for record ownership skew. I recommend taking a look at the following post to give you some ideas on how to prevent performance hits.

http://blogs.developerforce.com/engineering/2012/06/architect-salesforce-record-ownership-skew-for-peak-performance-in-large-data-volume-environments.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.