Mark Barcham of NZ Govt MFAT shares the upgrade of the Salesforce scholarship application community to use lightning flow. Be prepared to be impressed by the new stats!
2. 2
• 3 years in Salesforce
ecosystem
• Self-taught sole admin
• 2x Trailhead Ranger
• Certified Administrator
• Lightning Champion (2020)
• Not a developer!
Mark Barcham
System Administrator
Global Development and Scholarships Division
Ministry of Foreign Affairs and Trade
3. 3
Agenda
NEW ZEALAND SCHOLARSHIPS | Lightning Flows in Communities
• NZ Scholarships – overview
• Problem Statement
• Solution Overview
• A closer look at a Flow
• Results
5. 5
NZ Scholarships – Key Facts
Types of NZ Scholarships
• Tertiary study in NZ
• Tertiary study in the Pacific
• In-Country English Language Training
Scholarships
• Short Term Training Scholarships
• English Language Training for Officials
Scholarships
• Commonwealth Scholarships
• An NZD $90m p.a. investment in over 1000 new scholarships every year, for eligible
citizens from over 110 developing partner countries
• Studying in either a New Zealand institution or university (x12), or a Pacific
university (x4)
• 2 major service providers – Skills NZ and Accent Learning
NEW ZEALAND SCHOLARSHIPS | Lightning Flows in Communities
6. 6
NZ Scholarships – Key Facts
0
200
400
600
800
1000
1200
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019
Scholarships Available: 2010-2019
• Prior to 2016, applications were on paper (approx. 3,000 p.a.)
• Between 2016-2019, online applications between 8,000 – 13,000 p.a.
NEW ZEALAND SCHOLARSHIPS | Lightning Flows in Communities
0
2000
4000
6000
8000
10000
12000
14000
2011 2012 2013 2014 2015 2016 2017 2018 2019
Applications Submitted: 2011-2019
7. 7NEW ZEALAND SCHOLARSHIPS | Lightning Flows in Communities
Problem Statement
• Visualforce Community
• Authentication via RealMe – duplication galore!
• 3rd party Forms
• Complex dependent picklists
• Repeatable sections
• Users could access form from URL
• Poor User Experience
Forms
8. 8NEW ZEALAND SCHOLARSHIPS | Lightning Flows in Communities
The Solution
• New Lightning Community
• Forms replaced with Flows
• Authentication replaced with native SF
• Sandbox seeding using Prodly
• Conga Trigger to generate PDF of
submitted applications
PROJECT START – 30 September 2019
GO LIVE – 19 December 2019
13. 13NEW ZEALAND SCHOLARSHIPS | Lightning Flows in Communities
Dependent Picklists and Repeatable Sections
Level of Study depends on Account Country
Institution depends on Account Country
and selected Level of Study
Qualification depends on selected
Institution and Level of Study
Users can select multiple entries, to a
defined maximum
19. 19NEW ZEALAND SCHOLARSHIPS | Lightning Flows in Communities
Flow performance:
Applications Created – 88,295 (300% increase on 2019)
Applications Submitted – 29,419 (286% increase)
Eligibility Tests Completed – 191,747 (177% increase)
Enquiries – 4,723 (80% increase, but 20% decrease in login related)
Over 1 million flow executions during Jan-Feb 2020
Critically, 0 flow failures due to load.
49% of applications were submitted in
the final 4 days.
20% were submitted in final 12 hours.
Applications received from 79 countries.
Submissions increased from all but 7 countries.
Over 8,500 RealMe accounts converted.
Every year, New Zealand’s Ministry of Foreign Affairs and Trade deliver around 1200 new scholarships, enabling Scholars to study in New Zealand and the Pacific, valued at around $90m p.a.
Approx 110 developing partner countries
4 main types of scholarships (NZ tertiary, NZ English Language Training for Officials, Pacific Tertiary and Short Term Tertiary Study), each with quite differing needs
And a range of external providers (from tertiary scholarship providers, through to the learning institutes themselves)
Until 2015, we managed all aspects the Scholarships function in the Ministry directly, using a largely paper based and manual process – approx. 3k received p/a from 2011-2015
In 2016, we implemented Salesforce - to drive a more efficient and decentralised scholarships management process, including online applications through a customer community.
These changes have been instrumental in enabling us to move to a largely outsourced model
Initially successful – online applications in first year reached 13k.
But some of the design decisions made in 2016 caused a few issues with user experience resulting in declining applications year on year, reducing to 8k in 2019.
In late 2019 we embarked on a rebuild of the customer community to address some of these issues for 2020.
Today, I want talk more the design journey we’ve followed to do this, and how this affected applications for 2020.
Visualforce pages were inflexible in terms of development. Even adding simple messages to the page required coding and deployment.
Site authentication was done through RealMe. For overseas attendees, RealMe is a login service operated by the Department of Internal Affairs so users can access multiple government agencies using a single login. It is currently based on Artefact Binding which is not compatible with Salesforce so required a custom bridge application (hosted on Heroku). But RealMe doesn’t check for duplicates – 20% account duplication in 4 years over 140k accounts – and also cannot pass information downstream, meaning users had to enter their details twice: once in RealMe and again in SF.
3rd party forms had problems managing complex dependent picklists and repeatable sections. Had to use an apex class to formulate picklist values to pass into the form, and sometimes had issues getting the data back into SF. Occasionally would create duplicate records!
The form also had a visible URL – users could enter the URL and complete a form, even when we weren’t accepting applications, and without authentication meant it would be created linked to a dummy account with no contact details!
Application form is 9 pages of long-form answers. As form is external, data isn’t passed to SF until submitted. Loss of internet connectivity could result in loss of data, resulting in a less than ideal user experience.
New community built with Lightning. Using Builder, can easily add components (custom and standard), including the ability to easily add messages to the page – just drag and drop!
All three forms replaced with Flows. Two of them (Enquiry and Eligibility) can be executed by Guest user. Application cannot be executed as Guest, nor can it be executed when we are not accepting applications.
Authentication now done natively in SF. Existing RealMe accounts can be converted. Checks for email address duplication on Account.
Given the complex relational data in the org, we needed a way to reseed a sandbox with new data quickly. DataLoader was not going to cut it. We used Prodly AppOps fairly early in the project, which allowed us to seed a working sandbox in a matter of hours rather than weeks.
Work done by Davanti, with two MFAT resources co-located at Davanti for the project duration.
A closer look at the flow for the Application Form. Consists of 9 pages/steps, mixture of repeatable sections and long-form responses, as well as a legal declaration.
Note navigation at the top right. No indication as to what each page contains or which pages you have completed.
Next Page takes you to the next section, but does not save what you have done back to SF. This is only done when you click Save and Resume, or Submit.
Notice the form navigation on the right, clearly showing which sections have been completed!
Clicking Next saves what you have done on that page to SF using flow Update Record – less data loss!
Lets look at the Flow that drives this. It contains many elements to drive behavior, including navigation, retrieving and updating fields, validation checks and error handling.
This navigation is controlled with a hub-and-spoke model using a combination of the flow itself and wrapper and navigation Aura Components. This supports both linear navigation via the “NEXT” and “BACK” buttons as well as direct navigation via the side menu. The Aura Components determine what page the user is navigating from and to, then the Decision point in the flow directs the user to the appropriate page.
Repeatable Sections:- Two Study Programmes, three Study History and three Work History records can be added. Added records can also be deleted (although there must be at least one Study Programme).
Dependent picklists: - The data comes from different objects within SF.
1. Not every level is offered in every country. What you can select is based on the country the user is applying from.
2. Some countries can select Institutions in the Pacific, others just those in NZ.
3. The Qualification is selected from those defined on the Institution account at the Level that is selected.
All of these must be dynamic – e.g if we add a new Qualification to an institution account, it must immediately be available in the form. We do not want to be hardcoding anything into the flow logic.
Not everything can be done out-of-the-box. However, adding Lightning Components into flows is easy, and passing fields and values evaluated from the Flow into the component even easier.
The Application Flow uses 7 Lightning Web Components and 2 Aura Components.
Enquiry Flow uses standard Flow functionality, but it uses a Captcha Aura component if Guest user.
Eligibility Flow uses one Lightning Web Component to present and email a generated code to a Guest user.
In January when Spring 20 was released to sandbox, this component broke. Why? Guest user security CRUC – the code exists on a record field, which the guest user was no longer able to access. Sharing Rules did not resolve this. After discussion with Salesforce, we used the component code to retrieve the field value. Salesforce subsequently delayed the enforced Guest User Security CRUC into Production (presumably so they could resolve the Sharing Rules issue…?)
The Declaration screen contains elements of out-of-the-box and Lightning Components. FlowNavButtons appears on every screen to show the navigation buttons – reusable element. ShowSubmit determines when to make the Submit button available. It uses Component Visibility to determine whether to render the component, which then passes an event to the flowNavButtons component to enable the button.
In essence, if all of the tickboxes on the Declaration screen have been ticked, then Submit is enabled. Clicking Submit then runs through validation on mandatory fields, with an error returned if any are incomplete. The page list will show warning icons next to any incomplete pages.
When application is submitted, a background process launches Conga Trigger to generate a PDF of the application and attaches it to the Application object. This ID of the file is added to a field and used with the View button to open the file, which can then be downloaded if desired.
Quick demo of Application, Eligibility and Enquiry.
Note Eligibility and Enquiry should be done as Guest – line these URLS up in Firefox. Use Test2020 sandbox.
https://test2020-scholarship.cs26.force.com/Scholar/s/enquiry
https://test2020-scholarship.cs26.force.com/Scholar/s/eligibility-test
For Application, use Test2020 sandbox logged in as Testy McTestface (APN-104232).
So, what was the outcome of all of this change?
Data loss significantly less – each page movement saves data back to SF, and recovery from disconnections or timeouts handled better.
Most important, there were no issues with flow limits, even when we had tens of thousands of flow executions per hour in the final few days. Flow execution at scale.
Letter of Offer currently managed through Visualforce pages and Conga Composer to email copy of file.
This will be transformed to use Conga Sign (live July 2020), and signed letter file available to users on community similar to application file.
(Letter of Offer is a requirement for INZ to obtain visa, so user access to the file is critical)
Thanks to the team:
Davanti - Ming Lin (PM), Susan Bohme, Nadir Archor, Brendan Julian, Tu Dinh
MFAT - Pip Burcher (BA), Mark Barcham
PlanIT - Claire McIntosh (TA)
Conga – Damien, Ramiz and team
Prodly – Russell, “Stuff”, Jodi and team