Overview

There are a few options available to your project teams when it comes to using a mobile device to access your application or Salesforce configuration. Your project can choose to use Salesforce’s own mobile application, originally called Salesforce1 but now known as simply Salesforce, or take things much further and create their own mobile application, using the Salesforce mobile API to access the data and processes stored within the Salesforce platform.

Salesforce has tried to accommodate every use case in the use of mobile devices: those businesses that just want a simple solution that to some degree can mirror the main Salesforce platform’s browser experience all the way to those who want to create a bespoke application that allows the business to have maximum control over the end result.

This flexibility provides some complication to your governance team. In some cases they may have to govern your project’s solution just as they would any other programmatic solution, or have a light touch because the project team has chosen to access their functionality via the Salesforce mobile application.

As with previous phases of the Salesforce Platform Governance Method, this phase is broken down into sub-phases to ease governance, as shown in Figure 9-1.

If your project team is delivering a mobile solution as part of their overall Salesforce platform implementation, your governance team will need to understand initially the approach your project is taking. As previously mentioned, Salesforce has developed a number of options in the mobile solutioning space, some targeted at businesses that just want to deliver the basics to allow their end users to access key information on the move, while other solutions give developers complete control over what they do and how they do it (within the boundaries of using the appropriate Salesforce APIs).

Your governance team will want to review the process by which your project team came to the decision regarding what Salesforce technology to use. This is mainly because your governance team will be looking for the longer-term support and maintenance requirements as well as the resources needed. Developing a bespoke mobile application using, for example, Apple’s Swift development system might meet the business requirements, but will require your company to have those skills available for the long term to maintain and enhance the original. It is worth investing the time up front to determine whether your business requirements could be met using a simpler approach.

Mobile Strategy and Design

As shown in Figure 9-2, mobile strategy and design is the first sub-phase to be assessed by your governance team.

Govern the mobile solution for use of the appropriate mobile platform: HTML5, Native (iOS / Android), hybrid solutions, or Salesforce mobile app

As touched upon previously, your project team has a few options available to them when considering a mobile solution for their Salesforce platform application; however, these are really distilled into two types:

• Salesforce’s mobile app

• Salesforce’s mobile SDK

Salesforce’s mobile app provides a simple solution for delivering your applications and configuration built on the Salesforce platform to your mobile users. You can consider the Salesforce mobile app as really providing your end users with a similar experience to the one they have using the platform on a desktop PC via a browser. This solution is really targeted at your employees.

Salesforce’s mobile SDK provides a far richer development experience. It provides developers with the tools to develop mobile applications that your company can distribute through the Apple App Store or the Google Play Store, or others. These mobile apps can be used by employees, customers, or your partners. When using the Salesforce mobile SDK, your developers have a few choices regarding how they construct the mobile application itself, as shown in Table 9-1.

Table 9-1

Mobile Development Solutions

Mobile Development Solution	Description
Native	Mobile apps built specifically for a mobile device’s operating system. Each operating system that your company wants to support will require your development team to create a completely different application. For example, if you wanted to target Apple’s iOS and Google’s Android you would have to develop two different mobile apps and support and manage them separately. There are technologies available that can simplify this situation, but it is best to assume that every platform your company wants to support will require a separate application to be developed and tested. Your developers will use tools such as Apple’s XCode or Google’s Android Studio.
HTML5	Mobile apps built to be as portable as possible across the available mobile platforms. These apps are developed using the popular Web technologies HTML5, JavaScript, and CSS and are delivered using the mobile Web browser. Using these popular technologies provides the greatest flexibility when targeting multiple devices and platforms.
Hybrid	Hybrid apps, as the name suggests, are mobile apps built using HTML5 and JavaScript, but these are wrapped inside a thin container that provides native access to Salesforce’s platform features. You can decide to have your HTML and JavaScript code local or remote, which allows your developers to store data locally on the device or remotely on the server.
React Native	A React native mobile app uses a specialized scripting language and an older version of JavaScript (ES6 / 2015). CSS is handled via JavaScript code. React native provides access to the standard Salesforce mobile SDK features.

One of the challenges your project team will face before developing their mobile application using one of the preceding options is defining the business requirements they need to support. As some of the options presented are not native to the mobile platform you may target, your application may not have access to the mobile platform features it desires. Here is a summary of the features as Salesforce sees them, which are available depending on the development approach taken, as shown in Table 9-2.

Table 9-2

Mobile Platform Feature Access

	Native, React Native	HTML5	Hybrid
Graphics	Native APIs	HTML, Canvas, SVG	HTML, Canvas, SVG
Performance	Fastest	Fast	Moderately Fast
Look and feel	Native	Emulated	Emulated
Distribution	App Store	Web	App Store
Camera	Yes	Browser dependent	Yes
Notifications	Yes	No	Yes
Contacts, calendar	Yes	No	Yes
Offline storage	Secure file system	Not secure; shared SQL, key–value stores	Secure file system; shared SQL (through Cordova plug-ins)
Geolocation	Yes	Yes	Yes
Swipe	Yes	Yes	Yes
Pinch, spread	Yes	Yes	Yes
Connectivity	Online / offline	Mostly online	Online / offline
Development skills	Swift, Objective-C, Jaca, Kotlin; JavaScript (React native only)	HTML5, CSS, JavaScript	HTML5, CSS, JavaScript

Your governance team will be looking for assurance from your project team that the business requirements that need to be met are done so in the best way. This will be reviewed on a number of factors, as follows:

• Development skills within your organization and the ability to maintain the mobile app in the longer term

• Time scales required to deliver the mobile app; the HTML5 option removes the App Store requirement and therefore could be quicker to market

• Offline storage requirements, especially with regard to securely storing data

• Access to underlying mobile platform functions, such as the camera

• Application performance. Are your customers going to expect a mobile application that performs and is responsive?

• Look and feel. Customers can be put off from using a mobile app if the user interface does not adhere to their native mobile’s UI.

In the main, your governance team will not be looking to dictate to the project team the best approach, though they will be looking to understand the longer-term support for the project’s mobile app. Additionally, where a native solution is chosen your project will be required to participate in the normal software development governance processes, especially with regard to coding standards.

Testing may also be something of a consideration, and building a mobile app using HTML might be a slightly easier solution to test over a native solution.

Govern the authentication / authorization (including SSO), offline storage, and sync requirements

The Salesforce platform’s connected app is the primary means by which to connect a mobile app to the Salesforce platform. Your governance team will be looking for assurance that the project team has not deviated from this solution to authenticate their mobile app. If they have, then further assurance will be required to understand how the project team intends to handle authentication of a mobile app to the Salesforce platform.

The mobile SDK can use the SmartStore feature to store data locally for offline use. The lifespan of data within the SmartStore is tied to the authenticated user. If access is revoked, the data held within the SmartStore is purged. Your governance team will want to review the project’s use of SmartStore to determine whether the appropriate data has been stored and the lifespan requirement of any refresh tokens.

Your project may have opted to support advanced authentication, which is a configurable option and requires either MyDomain to be configured or Mobile Device Management (MDM) . Advanced authentication will require additional solutions for the MDM aspects, which will be used to distribute your mobile app settings. Additionally, using advanced authentication will prompt your users with a full-screen login page, which may leave some of your users confused, and they will be given the impression that they have left your application.

Your governance team should review the overall approach to authentication to determine whether your project is within your company’s security policy and whether the data that will be stored on the mobile device is secured, as well as whether that authentication will be implemented correctly. These areas of mobile app development will be the same whether your application is targeted at your employees or customers. However, you are likely to experience a greater number of users when targeting customers; therefore, your risk exposure could be greater.

Govern the use of Salesforce mobile app declarative design

Your project team may have opted to use Salesforce’s mobile app to deliver the functionality they require to their end users. This is a great solution that can provide the functionality quickly without the need to do a large amount of bespoke development. Just like with the Salesforce platform, however, your project will have to accept the look and feel as is, as well as a few limitations, as follows:

• The Salesforce mobile app does not support standard or custom Salesforce apps.

• You cannot use the console or agent console.

• There is no advanced currency management.

Additionally, some fields will behave differently on the Salesforce mobile app than on the browser-based Salesforce platform, such as the following:

• The division field is unsupported.

• Combo boxes are not supported. The text field element is available, but not the picklist part.

• User-defined lookup filters are not supported.

• Creating a record from a lookup field is not supported.

• Owner lookup fields always display the name of the record’s owner regardless of the user’s sharing permissions (this occurs on the Salesforce platform as well as on the mobile app).

• Disabled picklists are not greyed out.

• Phone number formatting is not supported.

• Creating or editing existing list views is not supported.

• Record editing in a list view is not supported.

• Multi-record selection in a list view is not supported.

• Mass actions are not supported.

• List views are not automatically updated when data changes.

• Kanban and split view are not supported.

• Collapsing sections on a record view is not supported.

• Some related lists are not available, such as the following:

  • Content deliveries

  • External sharing

  • Related content

• List buttons are not supported in some related lists; for example:

  • Open activities

  • Activity history

  • Approval history

  • Contact roles

  • Partners

• The notes and attachments’ related list is not fully supported.

• Uploading files is not supported.

It is clear to see from the previous list of limitations that there are a few considerations that need to be made. Your governance team should help the project team explore the use cases to make sure that the limitations are acceptable and do not detract from the original intent of the application itself. In the main, most of the limitations mentioned are acceptable. If you have a completely mobile workforce that only has access to a mobile device, then further consideration may be required. For many use cases, however, the Salesforce mobile app is a good compromise between accessing data and updating records when on the move versus using a laptop.

Mobile Security

As shown in Figure 9-3, mobile security is the next area of focus for your governance team.

Govern how the project has secured the mobile application and its data, including offline data encryption

There are a few techniques to use for securing the Salesforce mobile app and the data it uses. These techniques are as follows:

• Control the access to and security of the mobile application using

  • profiles;

  • permission sets;

  • passcodes; and/or

  • login IP ranges.

• Control what the user can do once inside the mobile application using configuration, as follows:

  • FORCE_EMAIL_CLIENT_TO

  • DISABLE_ACTIVITY_TIMELINE (iOS)

  • SHOW_OPEN_IN

  • SHOW_PRINT (iOS)

  • ENABLE_SHARE

  • DISABLE_EXTERNAL_PASTE

Your governance team will need to review the features that are allowable for your users so as to assess the potential security implications. For example, allowing a user to cut the data held in a Salesforce record and paste it into an external application may be unacceptable to your company. Any changes to the mobile application configuration will not take immediate effect on a mobile device. The application must be either exited (force quit) or the user must log into a new session. This can be forced by revoking all access to the mobile application, then re-enabling access. This in effect will force every user to reauthenticate and then receive the latest configuration.

If your project team has developed a bespoke application using the Salesforce mobile SDK, there are two main modules provided by the SDK, as follows:

• SmartStore is an offline storage solution that saves encrypted Salesforce data to the mobile device.

• MobileSync provides a mechanism for synchronizing Salesforce records with local records stored in SmartStore. This module effectively takes care of retrieving and upserting data.

• Key–value stores are an alternative solution to SmartStore, designed for simpler storage requirements.

SmartStore is a useful solution to storing the data your mobile application may need for offline use. It is also tied into Salesforce authentication. If this is revoked, the storage is removed along with the secure data. However, SmartStore provides a Global SmartStore that is not tied to a user’s authentication. Your governance team will be looking to the project team to provide a view of what data is being stored locally on the mobile device and in what configuration. Data stored in a Global SmartStore will require your project team to explicitly remove it.

Method

This is the formal method for Phase H of the Salesforce Platform Governance Method. The objectives of Phase H are to ensure that your project has thoroughly considered the implications of accessing Salesforce platform data from a mobile device using a mobile app.

Scenario

Back at Bright Sound Guitars, Hanna Snyder, the project architect, has brought a proposal to the governance team for her project’s mobile application. The business has decided to provide its sales team with a mobile app so they can be more efficient when on the road selling.

Hanna presents the basic principle of what she wants her project to deliver. Hanna talks the governance team through her mobile solution architecture. She’s looking to develop a native application that will be downloadable from the Apple App Store and the Google Play Store. She wants to target both iOS and Android mobile devices.

Her strategy is to have two teams develop native applications, one focused on using Apple’s Swift development system, while the other uses Google’s Android Studio development system. Each team will be fed the same requirements, and basically will try to follow the same “look and feel,” as Hanna puts it.

Hanna talks through the basic functionality that she expects the mobile application to provide the team of users. These are sales people, and they will need access to their opportunities, accounts, and contacts while on the road.

Hanna introduces Ranveer Shah to talk through at a high level how they expect to achieve this.

Ranveer mentions that they will use offline storage to store the data relevant to the user that has authenticated with the mobile application, which will provide the data that is most important to that user—mainly the account, contact, and any opportunities. Ranveer will integrate with the Salesforce platform through the Salesforce mobile SDK.

Having listened to Hanna and Ranveer, the governance team questions why the need for a native application. Hanna was not aware that there was an alternative approach, and asks for more details. The governance team mentions that the functionality that Hanna has described as the requirements could be achieved using the Salesforce mobile app. This app would more than likely over deliver on the functionality that Hanna is looking to deliver. Additionally, no development teams would be required, and the project could deploy the mobile application almost overnight, compared to the lengthy process of developing a native application and then the relevant app-store processes to publish the application for the sales team to download.

Hanna thanks the governance team and takes back their comments to the business to discuss further.

Summary

There are a few options to consider when looking to deliver a mobile app solution that integrates with the Salesforce platform. One of the key principles is to clearly understand your business’ requirements, and then select the appropriate solution that delivers just that. This is an area that can also evolve. Your project may find using the Salesforce mobile app a perfect solution in the short term, with a view to move to a more complex solution over time.

Phase H tackles the governance of your mobile solution architecture, focusing on the possible options to build and execute data sharing, visibility, and security that are required for a mobile solution.

During this phase you have highlighted to your project team the areas of concern and provided feedback as to what needs to be done to bring the mobile solution architecture within an acceptable level to pass governance.