As a marketer on the Salesforce Admin Relations team, I am quite familiar with Salesforce features and functionality. But I’m no expert…In fact, I would consider myself at the beginner Admin level. Recently, I built an app in Salesforce Lightning Experience to manage the Admin Relations team’s publication of content such as blog posts and admin stories, and the organization of webinars all in one place.
Through doing this hands-on project, I learned just how fun it is to build things, to be an app builder. If you haven’t tried to build an app for yourself or for a team outside of the basic sales app, what are you waiting for?!
Last year we re-launched the Admin blog under admin.salesforce.com and we developed a webinar program. With so much content being produced on a regular basis, we needed a way to manage who owned what, who reviewed what, what topics we covered, etc. So I started with a spreadsheet.
Like most initial “can we manage this in Salesforce” discussions, the idea for building an app came up as soon as I created the spreadsheet and presented it to the team. The response in unison was: “This is great, but at some point, we should put this in Salesforce!”
A spreadsheet would work in the beginning, but it wouldn’t become a scalable process like a business app in Salesforce would. I wanted an easier, more flexible way to manage content.
Figuring out what exactly you want to build is probably the hardest and most time-consuming step. I sat in this phase for a long time, noodling, brainstorming, thinking of wild ideas. I had an idea of what I wanted on the surface/visual level. But was blurry on the data I needed to capture. You think you need one thing and then soon realize you actually want something else. That’s why great admins know to ask their stakeholders why about 5 times – eventually you get to the real requirement!
Visually, what we really wanted was a calendar view of our content instead of a list of content with dates. We wanted a way to know where in the process different pieces were at any given moment. From a data perspective, we wanted to easily change content around, communicate updates with one another and report on content produced throughout the year.
Of course, everyone had ideas for bells and whistles and opinions of how to structure things. I found this out when I started talking to my stakeholders (you may know them: Mike Gerholdt, Kris Lande, Juliette Warren, Gillian Bruce and LeeAnne Templeman). Thankfully, Gillian and LeeAnne helped me boil down all the different ideas and requests into a Phase 1 and Phase 2 plan. Phase 1 included the basics (being able to replace the spreadsheet with a functioning app). Phase 2 was focused on leveraging the power of Salesforce to automate processes and create alerts.
Becoming a Builder
Building the app was the most fun stage. After having talked about requirements and app building for a bit, I had lots of ideas of how to build my app. So I just started trying things out. What was most tricky was designing a data model that was scalable and future-proof. I started with making lots of objects for all the different things I wanted to manage and track. With Mike’s guidance, I quickly learned that this was not the best way to set up the org. That’s when I learned about record types.
This concept is quite hard to understand when you’re a newbie but after trusting Mike’s advice and rebuilding my org, I started to see the difference and importance. For blogs and webinars, I was capturing very similar data and using the objects in the same way, so they shouldn’t be different objects, but one object with different record types. This makes management and reporting easier.
The Data Model
Multiple Developer Edition (DE) orgs and conversations later, I finally built a data model that made sense. I created a custom object called content with different record types for webinar, blog post, or podcast. I then created fields like: status, publish date, google doc, and post link to house important details for each piece of content. I built global picklists for the status field and customized what statuses would be shown based on the record type.
Next, I used the contact record to capture all the people involved in producing the content and created a junction object to be able to show how multiple contacts are involved in different roles as content is produced.
While I have added more customizations since this initial build, that is the basic data model that I’ve used. A lot of thinking went into this simplified model and it’s been working great!
The Lightning App
Building the app once I had all the right components was easy with the Lightning App Builder. I simply followed the steps in the app wizard. I customized the app by adding an image and picking a color. I added the tabs I needed and assigned the app to my team members, for whom I had set up with a specific profile.
The design of the record layouts and homepages was very important to me because I knew it would help drive adoption. I used features newly available in Lightning Experience to do this.
First, I used the “calendar anything” feature to show all the different types of content being published in a calendar view. I created specific list views that represent each type of content (like All Blogs, All Podcasts, All Webinars) and I made sure I filtered that list by status so it won’t show any canceled or postponed items. Then I created each calendar by following the calendar wizard. First, I selected the content object. Then, named the calendar and picked the fields to display. Lastly, I color coded the different calendars and voila!
Next, I customized the record page to include path. This way team members can quickly see the current stage for each piece of content. I created different paths depending on the record type since blogs have a different set of statuses than webinars. And, for one record type, I didn’t use path at all and instead created a compact layout.
Lastly, I experimented with creating customized home pages for my teammates with information I thought would be valuable to them.
As a proper Salesforce Admin should, once I had played around in a DE org and figured out what I wanted, I began building my app in a Sandbox that LeeAnne set up for me. I built out everything I mentioned above, from the record layouts, the user profiles and permissions, the object relationships, specific related lists, to calendars, reports and dashboards. It was a beauty! At this point, I learned the joys of deploying from Sandbox to production. That was fun…
If you are unclear about user and profile permissions, go try to deploy something from a Sandbox to production and you’ll quickly become an expert in finding ALL the places there can be permissions…Good thing I had experts like LeeAnne available to help me troubleshoot! We used a test profile to double check what the end-user would be able to see and do. And slowly but surely found all the places where I needed to enable permissions so my end users could interact with the app.
Once I was sure all of that worked, I demoed the app during our team meeting (for tips for successful demoing see this great post). And, then I added the rest of the team as users.
Future of the App
Before the app, I used a google spreadsheet to manage content. That worked ok for a while, but we kept growing as a team and creating more content, making it difficult to keep track of everything. Now, we have an app that lets us be that much more flexible and efficient. We use this content management app as part of our content production process. We review upcoming posts and webinars during our weekly meetings and I can make updates during our meeting. It also makes it really easy for me to report on how much content we’re producing.
I’ve already started planning Phase 2. The next app enhancements will be adding automation and alerts to some of our processes and integrations. I’m constantly thinking of ways to make the app easier to use so we can make content management more efficient. And, will keep you updated!
Have You Built a Lightning App Already? Share it!
Use #MyLightningApp on Twitter or the Success Community to share your use case or a picture of your app (without revealing private data!) by May 9th and we’ll randomly select 3 #AwesomeAdmins to receive an awesome swag pack!