Get your FREE 30-day trial.
Please complete all fields.
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.
Throughout this journey, 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, what are you waiting for? Sign up for a Developer Edition (DE) org and get started!
Last year, we re-launched the Salesforce Admins blog under admin.salesforce.com and we developed a webinar program. With so much new 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 manage this in Salesforce!”
A spreadsheet would work in the beginning, but it wouldn’t support 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.
Visually, we really wanted 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 i.e. my team. Thankfully, Admin Evangelists Gillian Bruce and LeeAnne Templeman 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.
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 by making lots of objects for all the different things I wanted to manage and track. With Admin Evangelist Mike Gerholdt’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 at first 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 don’t need to be different objects, just different record types. This makes management and reporting easier.
Multiple 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 contacts are involved in content 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!
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 steps. 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. 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. 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! And it’s at this point that I learned the joys of deploying from Sandbox to production.
I 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 the way I intended them to.
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.
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. I can easily update and change things and I’m able to create reports on content production in minutes.
Of course, development of the app is not finished. I’m constantly thinking of ways to make the app easier to use so we can make content management more efficient.
