3

I am planning to create a mobile app (html5 + node js) which will need both to take information and save information in salesforce. App users represent (person) accounts for the salesforce org.

My initial thought is: -create custom webservices as apex classes -design the app around them

There will be about 200k users for this app, but the org is small (2-3 enterprise license). Does it make sense to create the "integration user" and then let every app user use his credentials to access the APIs? Which limits will there be? How should I authenticate the app users when they access the app?

My actualy though is to: -design a RESTful server which will be bridge between 200k users and sfdc. -the RESTful server will have some over-night synch with the sfdc (no real-time data on sfdc) -the RESTful server will handle users' authentication on its own

Do you have any advice about this strategy? Which of the two is best?

Finally, is the mobile SDK articles that I've read designed for app which salesforce users would use? (i.e. do they authenticate with their sfdc credentials to use such apps?)

Thank you very much, sincerely T.

2

In practice, you have two choices: (1) create an integration user that syncs the data from your site or app to salesforce.com, or (2) purchase high volume, low cost licenses to manage users directly within salesforce.com.

The former method is relatively easy, but represents a certain security risk; the user has to have essentially system-wide privileges even though the users it services may not, so the session token must be closely guarded. Also, the code must be perfect or it may unintentionally expose data or allow writes when it shouldn't, etc. Also note that you don't get "extra" API calls by having only a few licenses, so this does not work in your favor.

The latter method is preferred, because you can have the users appear as actual users within the system, including the ability to "freeze" them, reset their passwords, enable or disable them on demand, and leverage the much higher API limits that you'll have available to you, avoid losing cursors on long queries, and so on. In short, it is technically superior in every way save one: cost. While salesforce.com may tout a given license type as "cost effective," that may not directly translate into "inexpensive."

I would advise contacting sales and see what licenses they might be able to offer you before trying to go at it yourself. However, having a single integration user may still be a viable option depending on the volume of data being transmitted. Real-time solutions will probably not be available, because you would presumably need between 10 and 30 API calls per each user that logs in each day, or far more if your application is "chatty." You could probably sync with salesforce.com more frequently than every 24 hours, such as hourly or bi-hourly.

The mobile SDK (now part of Salesforce1) is geared for direct salesforce.com interaction-- it would be expected that the application uses the mobile SDK to obtain OAuth tokens by logging in, in order to execute queries, update data, describe layouts, etc. You would not want to leverage the mobile SDK in a proxy-user ("integration user") experience, because that would be you'd be giving the integration user's session token directly to each client device to directly access salesforce. Using an integration user means that all traffic would be from the app to your server, and your server would talk to salesforce.com directly.

| improve this answer | |
  • Thanks, then I will see what salesforce sales can offer, but if 200k must translate into 200k licenses..mm that may be by far out of budget:) – T. Rossi Dec 1 '13 at 16:47
  • @T.Rossi They used to offer a Customer Portal license setup that was about 160,000 licenses for $1,000 USD/month, literally $0.00625 USD/month/user (6/10th of a cent). I'm not sure what they offer currently, but I'm sure there's at least one high volume license scheme that should work with your budget. – sfdcfox Dec 1 '13 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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