Salesforce Mobile Publisher: Technical Considerations

Now that you know what the main difference in approach between Salesforce Mobile Publisher and Custom App development is (see the article here on going mobile native on Salesforce), let’s take a closer look at the technical aspects of the Salesforce Mobile Publisher options. I’ll be referring to a project FLO CX (formerly bluez.io) has delivered for our Australian client, so all the practical hints are just subjective observations … don’t take them as a mantra, please :).

So what are the things you need to consider (our lessons learned) before you deep dive into LWC and mobile publisher?

Licenses

As the application is published to ios and Android stores using Mobile Publisher, which uses Salesforce Community Cloud, all you need are community licences. Alternatively, you can join the Mobile Publisher program to only utilise the platform. Our client went the Community Cloud path and initially opted for Community Plus licenses, which means additional functionalities, such as reporting, which come quite handy, i.e. Reports and Dashboards, within the Community.

We kicked off our engagement with our speciality, rapid prototype, delivering a tangible Lo-fi app in just less than 2 weeks. The app was done using a combination of standard and custom Lightning Web Components. The goal of this approach was to compare the out-of-the-box fit and the need for custom development to satisfy customer experience expectations. The outcomes were very positive, both approaches deliver outcomes, but with a different set of benefits, a classic trade-off between superior customer experiences and efforts in customisation.

The proof of concept proved all what had to be proven, but soon enough we were facing another round of decisions — how far should we go to further improve customer experience? We started from the most obvious candidate. Since the standard look and feel of dashboards was not hitting the mark, we opted for custom development of simple dashboard components, that meant additional work, but it really paid off.

Aura vs. Lightning Web Components

Based on the findings from the prototype, the recommendation was to build the whole application using Lightning Web Components. This approach comes with many points of consideration. At a high level, this is what you need to keep in mind:

• LWC is faster than Aura components

• It is not accessible using Developer Console, you need a CLI tool like Visual Studio Code

• In general, if you use LWC, the world is yours; you just need a good developer. Or read the manual

A very important lesson learned through this project — due to various reasons, we ended up using both Aura and LWC. This meant that some screens we were having both types of components, which needed to work together and exchange context — LWC needed data from Aura, which was simply not possible within the screen. As a workaround, we ended up with a classic hack type of a deal — wrapping the Aura component into an LWC container, so that this container can take the information and deliver it to other LWC components.

So, to make your life easy, try not to use both Aura components and LWC.

Custom Development Ratio

If you read between the lines of the previous sections, what comes next shouldn’t be a surprise. For the LWC + Mobile Publisher setup, you need to abandon the golden ratio of 80/20 standard vs. custom development. There is no drag-and-drop building in this game, and you will probably end up at 20/80.

It may seem odd, but to me, this is one of the greatest advantages of the platform itself. You can build a 100% drag-and-drop Community Cloud — if you respect the UI and functional limitations. Or you can use LWC and unleash the beast in exchange for heavy custom development. All of that within the same platform…it’s just a matter of choice.

Mobile and Desktop

Native mobile features

Clearly, one of the reasons why people build a mobile app ‘natively’ is because you want your users to have a mobile experience and have access to all on-device features :). That said, to what extent can Salesforce Mobile Publisher provide that?

Geolocation

Is actually quite straight forward — app can access native geolocation features and you can either use native Salesforce Map component or use iframe to embed anything. On our project, we did rapid prototypes for both approaches — ended up using none of them for MVP — not for a technical reason but due to legacy data issue. Otherwise I would say the native Salesforce component was way better than expected and very straightforward to implement.

Notifications

Starting Summer 19 release, you can incorporate push notifications into your mobile/web app, simply using process builder. Check this article for more.

Biometric ID

Using biometric ID has recently been enabled — both fingerprint and face recognition (also Face ID for iOS). More details in the manual.

Camera

Again, easy story — accessing native camera/upload picture functionality worked well. The native “upload file” screen though is not the UX-contest winner again, so we ended up building custom functionality for uploading pictures, that allowed compressing the picture and caching it within the browser / app. As usual, you would need to upload the picture to your org in order to process it, then attach it to a record that already exists in Salesforce.

Testing

Because testing is everyone’s favourite Friday afternoon activity, I mean it is a no-brainer, testing for user experience is a different beast. Using LWC and planning to publish the Community as a mobile application puts extra focus on a flawless user experience. To test this properly required three different devices with three different screen sizes, running on three different platforms. In short, on top of the functional testing, you need a ton of different devices to test the application.

Of course there are online emulators which can help, but there is always a gap, I’d say those 3 physical devices (not counting desktop) are a minimum to mitigate the risk of your application causing some customers or partners headaches. And remember, one of the reasons to utilise LWC was to attend and win a UX competition.

Do not hesitate to reach out with any questions — we’ll be more than happy to share the experience!

This article was published on the former bluez.io blog on October 3, 2019.