Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Anne Powell created a Lightning page with all the information and functionality a user could need at the right place and time.
The hiring process for any organization is typically a lengthy one. It often involves bits of information from all sorts of places that users need to view and interact with at any given moment throughout. To start, a hiring manager typically needs a candidate’s contact information and qualifications, the position details, and the interview information.
For a certain nonprofit organization, this information was found and maintained in several different places. For example, contact information lived on both the Application itself (a custom object) and the Contact record, which led to some frustration over not knowing which one was more accurate. They also used fields to input a candidate’s qualifications (think Current Job, Previous Job 1, Previous Job 2, etc.) which limited how much information they could collect. Lastly, since information was scattered, there were times when closed positions would still look open, so reviews were still being made for these applicants.
The first thing I did was review and restructure the nonprofit’s data model with the following end goals (with examples) in mind.
Once the data model was optimized, I tackled the user interface (UI) for the Application record page, which is where my users worked out of the most during the hiring process.
This interface now allows them to do quite a few things from the Application record, including:
In Lightning App Builder, there’s a plethora of standard components and functionality available to you to optimize the user experience. Let’s take a look at a few of those and how/why I used them in this case.
Ensuring users had the Position data handy when conducting reviews during the hiring process was incredibly important. So, to make sure that was always readily available, I used Dynamic Forms to display information on a related record without having to create several formula fields. This prevented users from continuing the review of an Application if the position had already been filled, which is indicated by the Status.
After changing the data model, the contact information no longer lived on the Application record, but rather on the Contact standard object. While I could easily display this information using Dynamic Forms and the master-detail relationship Applications and Contacts have, users needed to be able to edit a candidate’s information quickly (without having to go into a different record).
To satisfy this, I utilized the Related Record component, using the Candidate as the Lookup Field, and created an action on the Application object that updates the proper fields on the related Contact object. The layout you select for the update action will be the layout for the Related Record component when displayed on the page. Since the Candidate should already be initially created when going through the Application process, I left Create Action blank.
This allows users to update a candidate's contact information from the Application page without having to leave the tab. However, if they did want to navigate to the actual Contact record, they could simply click the header of the component (in this case it would be “Contact Information”) and it would take them there.
I wanted to allow users to view and add as many qualifications as they want and compare it with the position requirements without having to go into each individual Qualification record or the Contact record. Though it doesn’t have a direct relationship with the Application object, we are still able to access this list using the Dynamic Related List - Single component.
By setting the parent record to the Candidate lookup field, we can access the same related lists we would be able to as though we’re viewing the Contact itself and all from the Application record. On top of that, since it’s a dynamic component, we can choose how it should be labeled, the number of records, the fields to display, the sorting order, and, most importantly, the buttons to use such as the New action.
During the application process, the only time users should be able to submit reviews for an applicant is during the interview process. If they’re able to do so before or after that, it could lead to some issues. So, instead of teaching users to only do so at the right time, I used component visibility to display things only when they should actually be available. A few ways I used component visibility:
One of the pain points in the application process was having to open up different tabs at the same time to view information and collaborate. Before, users would have to compare the position details and requirements to the candidate’s qualifications by clicking in and out of tabs. To eliminate this, I utilized the “Header and Three Regions” template to make sure they were able to view position and candidate information side by side, as well as collaborate and view activity in a single place. This allowed for a highly functional workspace tailored to their needs.
While not necessarily a pain point, the My Labels component came in handy by letting users organize their applications how they wanted to. They were able to tag records with private labels and find them using those tags to quickly see the top candidates, for example, and which ones they should keep their eye on. It somewhat functioned as a private quick notes section when thinking on the fly.
This Lightning record page has sped up the application process by allowing users to view and do everything they need in one place. They won’t have to go find the applicant’s Contact record just to update their phone number. No longer will they waste time reviewing an applicant when the position is closed or if the candidate hasn’t made it to the interviewing stage yet. They also won’t have to keep two tabs open on their screen with the candidate’s information and the position information, since the information is now side by side.
When reviewing a process, think about whether this could and should be done all from one page and what would really help. While we can certainly come up with fields, objects, and screen flows to do what we need, sometimes the simplest thing to do is design a Lightning record page a certain way. Optimizing the UI optimizes the user experience and makes your users’ jobs that much easier!
Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Dee Ervin searched unsearchable field data […]
Welcome to another How I Solved It. In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Brandon Walton helped Family Bred Puppies […]
Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Erick Mahle improved user navigation within […]
