Three digital strategies for Salesforce Admins using Skuid pages

The role of Salesforce Admin comes with many diverse responsibilities. As a reference point, there are currently 113 admin modules on Trailhead! Today’s Salesforce Admins are tasked with so many areas of responsibility, including reports and dashboards, user permissions and credentials, your business’s data model, process automation, and mobile deployments—just to name a few. And with more and more tools at their fingertips, Salesforce Admins now often function as declarative developers, building complex, powerful applications with or without code. 

Salesforce MVP and founder of the SalesforceSaturday group, Steph Herrera, said on a recent Skuid panel discussion, “if you’re a Salesforce admin, it’s not enough to do what you’ve always done; you’ve got to step up and skill up...You’re driving your organization’s digital strategy.” In addition to the long list above, today’s Salesforce Admin is also tasked with driving their company’s digital strategy. With Admins taking on increasingly more disciplines, having the right tools at their disposal is critical.

Over the past eight years, I’ve had the chance to see how Salesforce admins use Skuid to make their lives easier. Whether it’s enhancing your reporting options or making sure a massive development effort gets off on the right foot, there are many ways that Skuid can help admins get a better product over the finish line. 

Common themes of the Skuid model 

There are a few pages that we’ve seen built time and time again, and we wanted to share those here. In these pages, you’ll notice a few recurring themes:

First, the “Skuid way” of building pages and apps, where you query whatever data you need and then display it using our component library, is the core DNA of customizing Salesforce with Skuid. So once you get the basic concept of building with Skuid models and components, you can use those tools to solve all kinds of problems. 

Second, Salesforce’s data modeling capabilities are amazingly powerful, but incorporating those capabilities into the front-end can sometimes be a challenge with out-of-the-box Salesforce. This is where Skuid comes in. The Skuid model and component framework lets you do a ton of customization that would normally require massive amounts of code. Throughout this post, we will call out areas where you can use Skuid to pick off some of those outstanding feature requests related to reporting or other admin tasks.

Page 1: reporting pages

Reporting is a huge part of the work week for many admins. Salesforce has a great reporting engine that makes it possible to slice and dice your data in all kinds of ways. But what some admins might not know is that underneath the hood, there are other tools to help developers build reporting apps - tools like aggregate SOQL queries. These queries let you pull aggregations and groupings of your Salesforce data, which is great for custom KPIs, leaderboards, operationalized BI, and a lot more. 

With Skuid, both admins and devs can create aggregate models to get those same aggregations and groupings so that they can be pulled into a page with actual record data, all without code, and you’re not clogging up your reports list. Aggregate SOQL queries are also quite powerful, with the ability to run aggregations and groupings on up to a million rows. These features make for some pretty cool combinations, like this account hierarchy navigation with account level KPIs and charts:

Any time you want something that’s more interactive, with the ability to edit and create new records, get to related data, see data real-time, consider creating an application with Skuid rather than simply running a report.

Every now and then, admins will want to report on objects that aren’t in the standard SF reporting engine. For instance, if you wanted to report on how permission sets are assigned across your org, or report on attachments so that you know how it will impact migration to Salesforce’s new file structure, you’ll have to go to custom code. That’s where a quick Skuid page can go a long way - these objects can be queried with Skuid models, just like any other. But it’s not just admin objects. Sometimes you’ll run up against a limitation that makes it hard to get the right information on a record detail page. For instance, you may wish you could get field history tracking on custom detail objects in a master-detail relationship - and because that’s just an object, you can pull those records into a Skuid page and show them in a table, enhancing your record detail pages with in-context reporting. 

Another great use case for Skuid models is reporting on the Chatter objects. Whether it’s a leaderboard of who’s got the most followers, or which accounts are getting the most activity, you can create a Skuid page with that data, no code required.

If you combine aggregate models with Skuid UI-side formula fields, you can create reporting pages with up-to-date rollup summaries and formulas that don’t count toward your formula limit on objects or rows in a report. You can also use these features to create rollup summaries that might not be available in Salesforce out-of-the-box, such as on standard relationships like Account and Contact, or on non-master-detail lookup fields. And with Skuid’s model conditions, you can make formulas and rollups as dynamic as you need, instead of being limited by static criteria.

Here we’re using a MODEL_LOOKUP formula (similar to VLOOKUP in a spreadsheet) to bring in Account pipeline aggregations:

The end result is that we can see Account details, pipeline data (like open opportunity totals and averages), and surface actions and information at the record level. We can easily send this information to our end user (in this example, there’s an option to email the Account owner).

You might be picking up on a theme here. Salesforce’s data modeling capabilities are really powerful, and we’re just piggybacking on that power. If you can query it, you can go pull it into a Skuid page where you’ll have all kinds of control over how that data is displayed and manipulated. That really opens up possibilities for what digital strategies and  reporting experiences can be, especially when you start to get into objects like ApexPage, the Lightning metrics objects, or for Skuid customers, the Skuid Page object.
‍

One last thing. It’s critical to keep your users in your application as much as possible instead of reverting to spreadsheets, and building these pages with Skuid helps you do this. You can build reporting functionality, processes and CRUD actions all into the same experience, on virtually every standard and custom object. But every now and then, your users still need to be able to export a report or list view so they can view it in a spreadsheet, which is why the Skuid export actions on tables and charts is such a useful feature on reporting pages:

And with that, we’ll move on to the next type of Skuid page for admins:

Page 2: data exploration & data management

This is something that’s become common practice for Skuid solutions engineers over the past six or seven years. Here’s the scenario: you’ve been pulled onto a project where the customer is either unsure of what’s in the data model, still working on the data model, or both. There’s a ton of custom objects and relationships, validation rules and Apex triggers that no one knows about, and maybe a complex security model too. So what do you do? 

First, make a data explorer page in your sandbox. Skuid models let you go get as much data from as many objects as you need in a single page. With that in mind, you can go create a new Skuid page, add the five, ten, twenty different objects or more that you think are part of the project, and then add as many tables as you need to the page to display that data. It’s one of the fastest ways to put something in front of your admin or stakeholder and say, “is this what you mean?” 

Many times the developers or solutions engineers looking at a POC are actually more excited about the data explorer page and how that can help them understand their apps and data than they are with the actual solution.

A data exploration page is useful in the following four ways:

1. Checking fields and relationships. Especially in old Salesforce orgs, you might have four or five fields with the same label, and knowing which one you want may be a challenge. Alternately, if the data model isn’t finished yet, you can let the project lead know they’re asking for a field that doesn’t exist yet (theoretically, yes, they should know, but we all know that there are communication breakdowns). Save yourself hours or days of back-and-forth by hopping on a call to walk through your data page with the project lead or admin.
   

2. Security model and rule testing. When you’re in the middle of testing, you might get a case submitted from a user who can’t see a field, or a field isn’t being updated correctly. What’s great about your data explorer page is that you can go to Salesorce setup and log in as the user with the issue, go to your Skuid page, and just look to see if the field shows up. If it’s a question about editing something, you can try to edit the field in the table to see if an error message shows. Quickly triage to figure out if the problem is in your Skuid build or your VF or Lightning code, or if you need to tweak your sharing settings.
   

3. Spinning up dummy/demo data. Sometimes you don’t know what data you need until you see all the objects working together. If you’re preparing a demo and you want to show your stakeholders data approximate to what they’re working with, a data explorer page can be helpful for quickly creating all the records and relationships that you need. With in-line record creation on your tables, and a table on each of your objects (including junction objects), you can hop on a call with the business analyst to quickly create that data in a single page.
   

4. Custom setting management. In Salesforce, using custom settings to manage custom metadata (like country code picklists) is made even easier, since you can create a Skuid model on a custom setting just like you would a normal Salesforce object. If you’re spinning up custom settings as part of the project, or even if you just need to see what you’re working with, a model and a table showing your custom setting in the data explorer page will save time and make your life easier.
   

Some additional tips: 

1. When setting up your Skuid page, save time by double-clicking on a model to auto-create a table with all the fields in that model. 
2. To speed up the process for creating demo/dummy data, add a “clone” row action to tables to quickly create new records with default values that you know will work.
3. Put a model on the UserRecordAccess object to assist security model testing.  This will calculate all the sharing rules and permissions to let you know what kind of access the running user has. 
   

Page 3: onboarding, resource directories

As the Skuid user base has matured, this is one that we’ve started to see more of. Let’s say you’ve been using Skuid for a while, and you’re starting to expand your team. You’ve hired some more admins, and you want to quickly bring them up to speed on your branding and style guide, common code snippets that you use throughout your pages, best practices, etc. You can actually build Skuid pages to make that onboarding experience smoother.

I saw this most recently at one of our customers, Mary Ann Liebert Publishers, where Salesforce admin Erik Wahlberg made a page to help new builders get going quickly. You can see in the page below, Erik has broken out core elements of how they build pages and applications, from page module organization to formula syntax:

Now, in this org, they’re extending Skuid with a little bit of Javascript in some targeted places. To help with onboarding, Erik created a “directory” explaining how those specific JS snippets work and where to use them:

You can see that it’s a mix of a “Getting Started” guide and a directory to help users navigate the building blocks of their application. 

Pages like this can work as a kind of “kitchen sink”, with examples of all the components you’re using, how they function, and how they’re styled. That’s actually what we did with our most recent release, Skuid Boston. Skuid Products & Application Engineer, Huyen York, created a fantastic page that shows each of the Boston features in action, with some text explaining how they work:

With the role of Salesforce Admin growing to cover increasingly more disciplines, having the right tools at your disposal is critical. Finding ways to step up and skill up will help admins accomplish the ever-increasing list of requests. Learn about the apps Skuid users love to use. Watch our Apps that rock webinar now.

‍