As a Salesforce admin, your job is to make the CRM work the way your users do. And while Salesforce is a powerful tool, adjusting it for maximum efficiency can be challenging due to its architecture.
Your company likely requires a complex data model to meet every department’s business needs. Yet, Salesforce architecture often requires users to understand your data model to find the records they must update.
Here’s something we once heard from a Salesforce solutions engineer: “Salesforce admins are often tasked with digital transformation, but what usually happens is a digital translation.” In other words, they've simply taken a spreadsheet or paper process and moved it into Salesforce. But, they haven’t transformed the way the user works when it comes to an easier experience or efficiency gains.
So, remember this any time you’re creating a new app: strive for a digital transformation, not just a digital translation.
How Skuid complements Salesforce
Before we dive into some data management tips, you should know that as a managed package, Skuid inherits everything you have in Salesforce. It works natively in both Salesforce Classic and Lightning and you can deploy it in Communities and the Lightning mobile experience, too
As you build Skuid pages by dragging and dropping components on the page, Skuid generates XML behind the scenes. So, it’s not creating Visualforce, Aura, Apex, or anything that might clash if you’re going between the Classic and Lightning experiences, and that allows it to be 100% native whether you’re building in any of those environments.
Skuid pages are split into data, visual, and logic layers, so that you can manage each one separately instead of searching through a block of custom code. That gives you the ability to go get any object (related or unrelated) and tie it with others (or not) and still have that rich layer of data on your page. Then you can separately configure how you want to display the data, be it in a table, chart, or form.
The ability to separate the data and visual layers is already a developer best practice. Skuid brings this capability into the admin world so that you can set up your data layer with access to all these objects and anything you might need, and then configure the way you present that data to the end user.
How a data exploration page helps with data management
Does this sound familiar? You’re on a project where the customer isn’t sure of what’s in the data model, is still working on the data model, or maybe both.
The data model in progress has tons of custom objects and relationships, validation rules, and Apex triggers that no one knows about. So, what do you do?
Here’s where Skuid can help. You can create a working prototype of the data model and share it with your customer to get on the same page. It’s one of the fastest ways to put something in front of your admin or stakeholder and say, “Is this what you mean?”
First, make a data explorer page in your sandbox. Skuid models let you retrieve as much data from as many objects as you need in a single page. So, you can create a new Skuid page and add all the project’s different objects, and then add whatever tables you need to display that data.
When setting up this Skuid page, save time by double-clicking on a model to auto-create a table with all the fields in that model.
Here’s more detail on how a data exploration page can help:
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 is a challenge. Or, if the data model isn’t finished, you can let the client know they’re asking for a field that doesn’t yet exist. 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.
Security model and rule testing. When you’re in the testing phase, a user may tell you that they can’t see a field or that field isn’t being updated correctly. With your data explorer page, you can go to Salesforce setup and log in as the user with the issue, go to your Skuid page, and see if the field shows up. If the issue is with editing, 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, your VF or Lightning code, or if you need to tweak your sharing settings. To assist security model testing, put a model on the UserRecordAccess object. This will calculate all the sharing rules and permissions to let you know what kind of access the running user has.
Spinning up 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 that’s similar to theirs, a data explorer page is helpful for quickly creating all the records and relationships that you need. With inline 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. To speed 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.
Custom setting management. Skuid makes using Salesforce settings to manage custom metadata (like country code picklists) 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 a 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.
Build better Salesforce reports and dashboards faster.
The Salesforce reporting engine helps you slice and dice your data in many ways. What you may not realize is that underneath the hood, there are other tools to help you build reporting apps—things 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 pull those same groupings into a page with actual record data, all without code. That way 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 a more interactive experience with the ability to edit and create new records, retrieve related data, or see data in real time, consider creating an app with Skuid rather than simply running a report.
Sometimes you may want to report on objects that aren’t in the standard Salesforce reporting engine. For instance, if you wanted a report on how permission sets are assigned across your org, or a report on attachments so that you know how they’ll impact migration to Salesforce’s new file structure, you’ll have to write custom code.
That’s where a quick Skuid page can go a long way. You can query these objects 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 example, 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 has 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 also 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 use these features to create rollup summaries that might not be available in Salesforce out of the box, such as standard relationships like Account and Contact, or 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? 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 pull it into a Skuid page where you’ll have all kinds of control over how you display and manipulate that data. This really expands possibilities for digital strategies and reporting experiences, especially when you get into objects like ApexPage, the Lightning metrics objects, or for Skuid customers, the Skuid Page object.
Remember that it’s critical to keep your users in your app as much as possible (and not reverting to spreadsheets). Skuid helps you do this by building the pages we’ve discussed here. You can put 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 are such a useful feature on reporting pages:
On failing fast
Sometimes you have to get something out there, roll out a minimum viable product (MVP), and get feedback on it to know that you're heading in the right direction. And there’s this whole concept of failing fast. And that just means identifying missing features or identifying problems sooner rather than later, before you've got really in the weeds of what you're doing and it becomes very hard to unpack.
Christine Marshall,
4x Salesforce MVP and author at Salesforce Ben
