Whenever Salesforce patches make their way into pre-release orgs our daily test runs kick off and identify the change. These tests run on 15+ org setups and report back any issues that might have been observed. One such observation was reported back during the early days of Summer ‘17 patch rollouts into pre-release. The issue manifested itself initially as the inability to complete the authentication flow on iOS devices built with Salesforce Mobile SDK v4.0.2 and lower.
During the investigations into the issue, we raised a notification on our trust site to keep our partners and customers aware of the risk of the behaviour. We also developed some internal work-arounds. If the issue wasn’t fixed prior to Summer ‘17 making it’s way into our partners’ sandboxes, these would let us unblock them from their development and testing processes.
We also discovered that the bug broke the vanilla experience of browsing standard Visualforce pages on iOS Safari; this could be bad if it got through into production.
An overview of Salesforce releases
Three times per year, a major Salesforce release occurs which introduces updates to its software. These releases happen automatically and affect everyone within the ecosystem, including regular customers and ISV partners with related solutions such as MobileCaddy.
These spring, summer, and winter releases are planned months in advance and are kept on a very precise schedule to allow for as much preparation as possible. The release cycle is made available to everyone, and Salesforce administrators are alerted via Salesforce’s own email alerts for admins.
Why is self-registration important?
The Salesforce Community Cloud is a way to connect both external users (such as customers, partners, and third-party resellers) and employees to an organisation, creating a digital channel to access and interact with, at anytime and from anywhere.
Community members demand constant availability of the digital processes and tools within, with emphasis on the self-service aspect of a mobile community experience offering the flexibility which creates real value for those users.
That self-serving nature can be improved further by adding the possibility of mobile Salesforce community self-registration. This removes a long-winded registration process, making the user’s digital engagement with the organisation even more seamless.
What is a Salesforce community?
A Salesforce community is an online platform for organisations to connect employees, partners, and customers, while providing seamless access to the data and records they need to get work done or complete tasks.
Built on the Salesforce Community Cloud, they offer real-time engagement and the ability to share any file, data, or record anytime and from anywhere.
It’s common to focus on functional requirements and usability when testing an application, areas which are often where most of the effort is spent once an app has moved into the testing, QA, and UAT phases of a project.
Before even thinking about any functional app code, though, it’s important to test all the app’s non-functional elements first. If those aren’t prioritised, not only will it have a knock-on effect on all other testing, it will also impact the app’s ability to function once deployed.
Defining, and clearly understanding, non-functional testing processes is the key to releasing a defect-free mobile app into production. When separated into two groups, these can be referred to as ‘initial’ non-functional tests, and ‘running app’ non-functional tests. But before we go into more detail, it’s necessary to understand why non-functional testing is unique for mobile.
One of the most exciting things about our Application Delivery Framework (ADF) is that it’s constantly growing and evolving, to allow our partners and customers to push the boundaries of what can be achieved with mobile apps on the Salesforce platform. As such, it’s vital that we help our community stay abreast of all the new MobileCaddy features and updates as they’re released.
With that in mind, I’ve decided to record and publish my regular discussions with Paul, our CTO, Todd, our Chief Mobile Technical Architect, and Frank, our Lead Product Engineer. In these sessions we’ll be covering what’s new with MobileCaddy, and will be sharing this with you to provide a first-hand look at everything we’ve been working hard on to improve.