This phase of the Salesforce Platform Governance Method focuses on the use of the Salesforce platform and your applications on a mobile device.
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.
“A solution architecture (SA) is an architectural description of a specific solution. SAs combine guidance from different enterprise architecture viewpoints (business, information and technical), as well as from the enterprise solution architecture (ESA) .”
—Gartner1
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
Govern the mobile solution for use of the appropriate mobile platform: HTML5, Native (iOS / Android), hybrid solutions, or Salesforce mobile app
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.
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. |
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 |
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
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.
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
Govern how the project has secured the mobile application and its data, including offline data encryption
- 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.
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.
Mobile Strategy and Design
Mobile Security
Approach
This phase requires that your project team supplies a few artifacts for the governance team to review. Your governance team will be looking to approve your project’s solution as quickly as possible, without necessarily knowing all the details of the mobile app being developed.
With this in mind, governing the mobile app will take the approach of an initial review, where your project team presents the overall mobile app development approach, such as whether it is a native, hybrid, or HTML app, and outlines the basic business requirements.
With that review over, your project team could then dive into the details of the business requirements and talk in more depth about their approach to authentication, data visibility, and offline data storage and security. Your project team should look to include these requirements in a sharing matrix, as discussed in Phase I.
Inputs
Project sharing requirements
Project completed Salesforce external user sharing resource matrix
Project sharing requirement options
Mobile app development approach
Offline data requirements and storage
User authentication solution
Steps
The steps to govern your project’s mobile app will help the project team deliver a quality solution that your business can be confident meets your security requirements and has considered the secure storage of offline data.
Your project will develop a mobile application that is supportable in the long term by selecting the appropriate technology in which to develop the mobile application.
Mobile Strategy and Design
- 1.
Govern the mobile solution for use of the appropriate mobile platform: HTML5, native (iOS / Android), hybrid solutions, or Salesforce mobile app
- 2.
Govern the authentication / authorization (including SSO), offline storage, and sync requirements
- 3.
Govern the use of Salesforce mobile app declarative design
Mobile Security
- 1.
Govern how the project has secured the mobile application and its data, including offline data encryption
Outputs
Not Applicable – This phase in the Salesforce Platform Governance Method is not applicable to the project.
Remediate – The governance team requests that the project team remediates its design to accommodate the issues raised during the governance review.
Pass – The governance team has found no issues or concerns with the project’s proposal and therefore the project has passed this governance phase.
Review – The governance team has found the inputs cannot be objectively measured and therefore a subjective view has been made, which will lead to a discussion with the project team to reach consensus. Although undesirable, this could be a consequence of unclear standards/policies.
Scenario
Govern the mobile solution for use of the appropriate mobile platform: HTML5, native (iOS / Android), hybrid solutions, or Salesforce mobile app
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.