Enterprise Mobile Patterns

Design patterns have long been critical to developer productivity, rapid onboarding of new staff, and the creation of scalable, maintainable solutions. The Salesforce App Cloud and the mobile patterns described in this document have been assembled based on conversations with hundreds of developers and customer building successful mobile apps. Any developer, or organization building mobile apps on the Salesforce App Cloud will find this collection of patterns invaluable to delivering engaging apps connected to customer data.

Understanding Connected Apps

A core feature to the Salesforce App Cloud is the ability for mobile services to leverage Connected Apps. Connected Apps are any application that connects to Salesforce Services using OAuth Authentication; most typically, but not limited to, mobile apps.


Developers, or administrators, can rapidly create a connected app endpoint, define API permissions, including whether pin-code protection must be enforced on the mobile device for the app. Connected Apps enable adminstrators to define organizational policies for mobile apps.


The patterns decided in this paper, rely on the Connected App configuration. Connected Apps can be created using the following steps. For more detailed discussions on Connected Apps please refer to the online guide.

  • Navigate to Setup > Create > Apps, and click “New” Connected App
  • Enter the name of your app in the Connected App Name. This name must have no spaces, and will be displayed to the user as part of the authorization ‘allow-deny’ step.
  • Enter the Developer Name of your app. This is actually the API name that can be used to reference the app via code.
  • Enter the developer contact email.
  • Specify a callback URL for the OAuth flow. For mobile apps, the specific URL doesn’t have to be a URL available on a web server (as that doesn’t make sense for a mobile app). I use: mobile://success
  • Decide how you want to scope access to services and customer data
  • Select mobile for the supported app type, and if appropriate, choose to enforce pin-code protection.
  • Save your connected app.

The Patterns

Design patterns provide a repeatable, proven implementation practice. The following collaboration diagram provides a high level view of the key enterprise mobile patterns, and how they relate to each other, and the Salesforce App Cloud.


To facilitate learning, a complete reference application, Cloud Cable has been created. Cloud Cable includes an implementation of each of the patterns described below and can be downloaded from github.

Mobile Facade Pattern


Every database object within the Salesforce App Cloud is instantly enabled with REST services for CRUD (Create Read Update Delete) operations. This eliminates the need for developers to hand code, and maintain, mobile endpoints. However, there are times when developers need more coarse grained service calls such as those that batch requests into a single call to handle low bandwidth, require transactional support across multiple updates, or service calls that are required to work across multiple related database objects.

The Mobile Facade Pattern provides a facade wrapper atop database object level REST services, and exposes a single coarse grained REST endpoint for developers. Mobile app consumers are typically pre-authenticated to the the Salesforce Platform backend services, or the Mobile Facade is implemented in conjunction with the Anonymous Reader Pattern.

The following diagram depicts a typical implementation that uses the Mobile Facade Pattern to support transactions across a single business process.



The Mobile Facade Pattern is implemented as an Apex class using custom Apex REST endpoints. It is considered best practice to group related coarse grained custom endpoints into a single Apex class. This approach encapsulates common functions and promotes re-use across endpoints by leveraging helper methods. The following article, provides a detailed description on how to implement a mobile facade:

Creating REST APIs Using Apex REST

Next Steps

Mobile Facades are an extremely efficient way of working with backend customer data and leveraging the Salesforce App Cloud's ability to dynamically generate JSON responses based on database objects. By default, REST endpoints require OAuth authentication for consumer to access customer data. The Mobile Facade pattern can leverage the consumer key generated via the Connected App services to retrieve the required OAuth token.

Anonymous API Pattern


The are many times, in particular for consumer mobile apps, where data is required for anonymous users. The most typical example may be a storefront, or non-confidential information. Developers can expose REST endpoints for anonymous (public) access via the Anonymous API Pattern whilst still controlling data visibility based the roles and profile features of the Salesforce App Cloud.



The Anonymous API Pattern relies on Force.com Sites, and an Apex class, or database object, to expose as an anonymous REST endpoint. For our example, we will create a simple TODO database object and expose that.

  • Navigate to Setup > Schema Builder
  • Click the Elements tab, and then click & drag “Object” onto the schema browser


  • Complete the new object setup with the following values, and click save


  • From the object palette, drag a text field on the TODO object, and enter the following details, then click Save


  • Now we have our custom database object, we can create custom logic, and expose as REST endpoints. Navigate to Setup > Develop > Apex Classes. The following code is an example of a custom REST endpoint using the Salesforce App Cloud annotations


  • Create a Force.com Site by following the steps included in the Introduction to Force.com Sites article, section “Creating a Site”. (Make sure that you click “Activate” to make the URL public. For mobile app developers this is all that is required to expose an anonymous REST endpoint.
  • Click “Public Access Settings”, and set the Custom Object Permissions to what is required of your app. Click Save.

This is an example where the mobile services leverage existing features of the Salesforce App Cloud to enforce database object level access.


  • Scroll down to Enabled Apex Class Access, and click Edit. Select the TodoController, click Add, and Save.


Next Steps

The Anonymous API pattern exposes a RESTful endpoint using the following format that can be used by mobile developers to anonymously access information based on either a custom object, is using the Mobile Facade pattern, multiple objects (note: if using the Mobile Facade pattern, developers must enable database object permissions for each object used within the facade). The use of how many API calls can be made via this pattern is governed by the number of Force.com Site calls the user has licensed.


The specific URL is unique using the following values, and based on the mobile service annotations in your custom apex class (step #5), may be accessed using HTTP methods (GET, POST, PATCH, DELETE) with tools including Apigee or Hurl.

MysiteName = the name of the Force.com site you created in step #6 PodName = the managed platform ‘cluster’ your mobile services are available on. You can get this number by looking at the URL of your browser whenever you are logged into the Salesforce App Cloud backend. urlMapping = the URL mapping you specified when creating your custom Apex class in step #5

Customer Portal Facade


The Salesforce Platform provides the ability to create a customer facing portal. Mobile app developers can leverage this capability to enable services including Social Sign On and self-registration. Many of the typical portal features such as branding are not required for the Customer Portal Facade Pattern, and can be skipped or left with default value. The key for mobile developers is the portalid and orgid that is generated when creating a customer portal.



  • Navigate to Setup > Create > Customer Portal
  • Click New, and enter details similar to the following, and click Save.


Then, associate the API Portal User profile to the Portal. Note: The API portal user is the profile we assign to new users that get created via our registration handler


Next Steps

The Customer Portal Facade is a foundational pattern of the Salesforce Platform Mobile Services. By creating a Portal facade, developers now have access to a portal id which they can use to authenticate, and provide self-registration to users via mobile APIs using the Auth Handler Pattern.

Registration Handler Pattern


Secure authentication to enterprise mobile apps is a critical aspect to user adoption, and the ultimate success of mobile apps. Developers can leverage the Auth Provider capability of the Salesforce App Cloud to provide authentication via Facebook, Salesforce Identity, or Janrain for other social networks. Creating an Auth Provider gives the developer the option to include a custom Registration Handler.

The Registration Handler Pattern is implemented as an Apex class. Developers can add custom logic to be performed as part of the authentication process. In particular, Registration Handlers are most frequently used for the creation of a User record, assigning appropriate roles and permissions, and creating related records for reporting mobile app usage.



The following implementation of the Registration Handler Pattern creates an Registration Handler with custom logic to create an Account (the mobile app) and Contact record for reporting on mobile app usage, as well as creating a User record with API Portal User access (typical for most mobile implementations).

This pattern demonstrates a typical archetype of successful enterprise mobile apps - leveraging the native features of the Salesforce platform in conjunction with App Cloud mobile services - Specifically, using the Account object to identify a mobile app for reporting and workflow purposes.

  1. Navigate to Setup > Security Controls > Auth Providers, and click New
  2. Select Facebook from the Provider picklist
  3. Complete the required fields, using the consumer key and secret from a valid Facebook App. (See Configuring a Facebook Auth Provider for full details - (login required))



  1. To complete the Auth Provider setup, you also require a portal to allow anonymous login and self-registration. (see Customer Portal Facade Pattern)
  2. Select a user to run the Registration Handler as. For mobile development, a good practice is to create an “integration user” within the Salesforce App Cloud to allow the decoupling of mobile app permissions from other users. This approach allows encapsulated management of permissions. (Note: whatever user you use, it must have the "“Manage Users" permission on the associated profile, and a role assigned to the user)
  3. Finally, click Automatically create a registration handler template. This will create a stubbed Registration Handler. For most implementations, the template is sufficient to create a user. For our example, we are going to associate the registration with an Account to more effectively track mobile app usage, and leverage many of the Salesforce App Cloud's business services such as reporting.


  1. Once your Auth provider is configured, return to your Force.com Sites configuration and enable Login Settings using the customer portal setup earlier. (more detailed information can be found here)



Next Steps

The Registration Handler Pattern, upon successful implementation (successful save of the Auth Provider, and implementation of a Registration Handler), developers will be provided a single sign on URL. This URL, along with the connected app model of the Salesforce App Cloud enable the foundation for building secure mobile applications connecting to customer data.

Organizations who implement the registration handler pattern can then engage internal or external development resources to build mobile apps with the ability to leverage a standards-based approach to authentication for all mobile apps.

Mobile Platform Pattern


Many organizations become focused on whether they should be web, hybrid, or native mobile applications. There are certainly pros and cons to each approach which must be considered, however, too often, businesses become focused on a verses approach to mobile app development rather than a broader organizational approach. The mobile platform pattern shifts the development of a mobile strategy from end-devices and apps to one that leverages a cloud-first approach to promote re-use across the entire company.


Unlike the other patterns presented here, the Mobile Platform pattern is best described as a series of strategies for each type of mobile app: web, hybrid, and native, and how they can be developed using an enterprise mobile platform such as the Salesforce Platform.



100% web apps delivered via the browser using HTML5, JavaScript, and CSS technologies offer a rapid development option especially for organizations who have little prior mobile app development experience. Leveraging the mobile packs provided for the Salesforce App Cloud, developers can use many of the leading JavaScript frameworks including Ember.js, Backbone.js, and AngularJS to securely connect to customer data.

Organizations looking at 100% web applications should consider building single process applications - apps that perform one business process well, eg: work with tasks, create/view/edit appointments etc. This process avoids some of the potential downsides, such as memory management of large data sets within the browser cache, of pure web applications, but allows the rapid creation of mobile apps that support any platform/device without the need for highly specialized mobile app developers.


Hybrid applications, in particular those that leverage the Salesforce App Cloud's mobile SDK for secure authentication and access to local device functionality to achieve core business requirements like secure offline storage and pin-code protection, are a highly effective strategy to bridge existing developer skills with the needs of native device support.

Organizations looking at hybrid applications should consider building line of business focused portals that aggregate many 100% web applications into a complete business solution. This hybrid portal approach allows an ‘economy of scale’ for development by centralizing core functions such as authentication, and app distribution. Developers and and IT departments can build common services on the platform to work with corporate data and make these services available to any app (see mobile facade), without the risk of slowing the agility of lines of business building 100% web apps. Further, with access to local device functionality, organizations can deliver additional benefits by integrating cloud-based services into local device services. eg: integration with local contacts, and calendar, and make these available via the mobile platform and other apps.


Native applications provide a rich, optimized experience for mobile applications. The mobile SDK for iOS and Android empower developers to build native apps to leverage the Salesforce platform, but do require specialized skills, and separate code bases to support multiple devices.

Organizations looking at native applications should consider delegating the majority of business logic to the mobile platform. This approach greatly reduces the complexity on the native device, and mitigates the need to the duplication logic on different devices. eg: a company supporting both Android and iOS may need to support bank account transfer functions. Developing this functionality in Objective-C (for iOS) and in Java (for Android) is not a scalable solution for even the largest organizations. Delegating this logic to the mobile platform leverages existing skills, and makes the development of common services a core aspect of the organization’s mobile strategy.

Next Steps

Many organizations get focused on whether to build web, hybrid, or native mobile apps. The Mobile Platform pattern takes a cloud-first approach to mobile app development that allows organizations to focus on business agility, and existing skills, resources, and experience. Organizations looking to implement the mobile platform pattern can start small with a line of business 100% web mobile app, and grow this over time to meet the broader mobile demands of the business.


The Salesforce App Cloud provides the most complete set of services for building enterprise mobile applications connected directly to customer data. The enterprise mobile patterns detailed within this paper provide the fundamental implementation patterns used by hundreds of successful customers. Developers looking to master the Salesforce App Cloud mobile services must become familiar with these patterns, and how they can leverage the rest of the Salesforce App Cloud to deliver game changing mobile apps for their customers, employees, and partners.

About the author

Quintonprofilepic-withshadow.png Quinton Wall is a Director of Tech Marketing at Salesforce.com , and aspiring fantasy author. He is a regular speaker at cloud and developer events around world, active contributor to open source projects, and the developer.force.com site. When he is not working with the Force.com platform, building mobile apps, or writing books, he can be found on twitter @quintonwall sharing his thoughts 140 characters at a time.