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.
So what’s new with MobileCaddy this month?
Operating and supporting any enterprise application in the context of mobile is challenging, because you don’t have control over that app’s underlying operating systems, nor can you predict new updates, upgrades, or patches being released.
This presents a problem for those responsible, because changes to an OS can cause mobile apps to suffer in their performance, or even stop working entirely. When those apps have been deployed into functions which are critical to the daily running of the business, that effectively renders the employees or community users relying on the app incapable as well, which simply can’t be allowed to happen.
So, firstly… Understand your app
You need to be aware of all the various components which make up your application, how they interact with each other, and what relationship they have with the OS.
Any number of things within your app can change without your knowledge, and the various elements and supported systems mean that continual testing is an absolute necessity to avoid app failure. This becomes even more important when applications are supporting business critical processes and workflows.
StreetLink is a UK-based nonprofit service which allows members of the public to alert their local authorities to rough sleepers in their area. The service has helped thousands of people find support and shelter thanks to a number of available channels of communication.
Those channels of communication function through various technologies, with a phone line, website, and mobile app each enabling members of the public to contact StreetLink, who then pass the information to the local outreach teams to locate and provide rough sleepers with assistance.
Code deployment validation
With the MobileCaddy Application Delivery Framework (ADF), code deployment is made simple from a developer’s perspective, thanks to the CodeFlow development environment. CodeFlow enables one-button deployment, from the developer’s local environment up to the Salesforce platform. This bundles up the application logic, UI, and much more into one simple flow.
Following this, an extremely important step in the testing is to ensure that code has deployed successfully. By using the MobileCaddy Platform Emulator, along with the browser’s development console, developers can validate the code immediately after it’s been deployed. This is beneficial because a partially failed deployment, or missing assets, will be picked up for correction before any QA or UAT processes begin.