top of page

Search Results

54 items found for ""

  • No Dreamforce Wrap-up From Me

    If you've been reading my blog for a while, you might have noticed that I didn't publish a post-TDX wrap up, nor anything in particular about Midwest Dreamin. And I'm not going to write a Dreamforce '23 wrap up either. Why? It's Been Done For starters, there's more than enough other content already out there on LinkedIn, the social media site formerly known as Twitter, the Trailblazer Community, Ohana Slack, and probably more. With the activity of some social posters you can practically experience Dreamforce in realtime, if you want to. By the time I would write something up it's practically stale! And I am happy to encourage you to read some of the other excellent Salesforce blogs out there, many (or most) of which did have a wrap up. So I don't think you really need one from me. Mostly Marketing Also—spoiler alert!—the content at Dreamforce is mostly marketing. [I hope this isn't coming as a great shock to you. If it is: You're welcome.] I actually don't mean that as any sort of complaint. Really. Salesforce spends millions of dollars on Dreamforce and the purpose of the conference, from their perspective (as I interpret it) is to sell product. It's a fun conference, incredibly well produced (think Disney level of attention to visual detail, but for a tech conference), with free access to a concert from a headline band (this year: Foo Fighters, my first time: U2), and interesting to experience. But the keynotes and the Salesforce-generated content are a chance for the company to make announcements about shiny new things and to generate interest and hype that will get good press and eventually result in profits. No more, no less. The nonprofit keynote had a surprise visit from Sprinty the T-Rex, and that was pretty cool. But it's hardly groundbreaking new announcements of features or products. And the actual "announcements" in the nonprofit keynote (to the extent that I paid attention) were all "AI blah blah" and "GPT blah blah." Nothing that we're going to be using for a while. (I'll write about that stuff when it seems actually relevant.) Before COVID, when Dreamforce attendance topped 150,000 (not a typo!), there were thousands of sessions presented by community members (like me), so there was a massive amount of learning and technical content available. In the post-COVID incarnation of Dreamforce attendance is lower and the number of presentations from outside Salesforce has also been reduced. It's hard to say if it's a proportional reduction, honestly. But if you're really looking for technical learning, you can get it at dozens of Dreamin events for less cost, so I would argue that Dreamforce is just a different thing. That's not to say you can't learn a lot of technical content at Dreamforce. You definitely can. You just have to learn to read between the lines of the session titles and abstracts. Tons of Networking So if Dreamforce isn't for the technical content, why did I spend the money on airfare and hotels? I actually didn't think I was going to bother until the Trailblazer Community Team decided to have a Salesforce MVP Hall of Fame induction ceremony and an all-day conference for MVPs. How could I pass that up? For me the event is about the networking. I saw and met tons of people. As an introvert, it's an amazing opportunity to sit down and go deep so that we really bond. (It's also incredibly overwhelming as an introvert, but that's a topic for a whole blog post sometime.) But it doesn't feel like a Dreamforce wrap-up about all the networking I did would be that interesting... If you weren't there, do you care? Which brings me to my main feeling about Dreamforce recap blog posts: Do people care? If you were there, you don't really need the post. And if you weren't there, am I just lording over you that I was? FOMO Much? If you read this post and all the other Dreamforce content and wondered whether you were missing out, I'll leave you with this bit of advice: Dreamforce is something to experience at least once. It doesn't have to be next year and it doesn't necessarily have to be a regular thing. In fact, I wouldn't even put it first on your list: TrailblazerDX (or TDX) has a lot more opportunities for technical learning and is focused on developers and admins. And it's also run by Salesforce, so you get a lot of the Dreamforce magic, but with fewer crowds. Dreamin events are far cheaper and easier to get to. Content is much more focused on admins and job seekers. You could probably attend three Dreamins for the same cost as going to Dreamforce. Local User Group Meetings - These are, by definition, local and they're also free. Go meet other professionals in your area! If you're involved in the ecosystem I would recommend you try out Dreamforce sometime just to say you have. But see if you can get an employer to pay for the airfare and hotels.

  • Smiley Faces Form

    If you'll indulge me, I'd like to brag a little bit about my son Arden while telling a frame story about making a cool FormAssembly mod. A few weeks back Jennifer Lange asked the FormAssembly VIP Slack community if anyone "has a scale of smiley faces that can be clicked to report your experience with a service? One question "How was your service today?" and then 5 faces - click one to rate and then submit." She pointed to a FormAssembly model that was close to what she wanted, but with stars instead of smiley faces. I immediately wrote that five radio button options in order like this would do the trick: 😭 😢 😑 🙂 😄 I was reading too quickly and didn't notice that she also said "NOTE: I know I can put an image of 5 faces, and then have the radio buttons under them - that's not what I want. I want clickable face images." Hmm. The code on that form seemed pretty understandable, but since we weren't going to repeat the same image five times I wasn't sure how to go about modifying it. Fortunately my son Arden is home for the summer. Time to call in help from the CS Major! It took Arden and me a couple minutes of fiddling but the result was this form (with code that you can reveal and use for yourself.) Cool right!?! Go use it for something in your org. And tell me what other fun FormAssembly tricks you've found!

  • Free Things I Always Install: Unofficial SF

    This is the final installment of my summer series of posts about free utilities I always install in a new Salesforce instance or that I install into existing instances once I come along to support them. I love free things! (These, by the way, are all free-like-a-beer.) UnofficialSF ("USF") It's the last post in this series, so I'm not limiting myself to one tool, I'm pointing you toward a site with hundreds of them. UnofficialSF is "a loose collaboration of bloggers, mvp’s, and the occasional Salesforce employee" that put out "Guides, Installable Actions and Components for Salesforce’s Automation Products." If you haven't browsed the amazing things people have built, I won't be offended if you switch tabs right now! The Flow Components library alone is a treasure trove! Look also at the Lightning Page Components if you want to customize your user experience. (You might even find something familiar looking on Applications and Utilities... 😉) What I Install As I said, there are a ton of great tools here that just might be exactly what you're looking for, even if you don't know you're looking. Several of them have been exactly that for me at one time or another! But I don't want to clutter up client orgs with more installed packages than I'm going to use. So when it comes to the ones I always install, I limit myself to the USF components that I need right away or am pretty confident I'll be using in the near future: Flow Action and Screen Components BasePacks - These are a required prerequisite for several USF tools so you might as well install them early. (Otherwise you're just slowing yourself down when you try to install something later.) With these in place other USF components can install and even have configuration tools within the Flow Builder. Navigate Everywhere - We've all been frustrated when building a screen flow and want to redirect the user to the record we just created. Navigate Everywhere gives you that power and more. Might not be used right away, but it's likely on the menu as soon as you I build a screen flow that creates records. Send Better Email - I used to use this all the time, if only for the ability to log an email as a task on the contact once it's sent. But that's now part of the standard SendEmail flow component, so SBE might not be as critical anymore. But SBE still gives other functionality that can be handy, so I like to keep it around. Datatable - The Salesforce standard Data Table component is getting more useful, but it still can't do all the things you're going to want and need. USF's Datatable sets the real standard for displaying and interacting with records in a table in a screen flow. Gratitude While I'm mentioning USF, I want to give a couple of special thank you: Alex Edelstein - I don't think I've ever met Alex. But I, like many, owe him thanks for starting and maintaining UnofficialSF. Eric Smith - There are many people that publish and maintain components on USF, but Eric seems to be the author of ones I use most often. I've been fortunate to hang out with Eric in person and also fortunate to get fast responses and help when trying to make one component or another do my bidding. Thank you, as well, to everyone that creates, publishes, and maintains the tools on UnofficialSF. Whether you've made one or many, you've helped me and many others do our jobs better.

  • Free Things I Always Install: DLRS

    This is the third in a summer series of posts about free utilities I always install in a new Salesforce instance or that I install into existing instances once I come along to support them. I love free things! (These, by the way, are all free-like-a-beer.) DLRS (Dolores) Getting a post out of this is almost cheating because I wrote a whole post about DLRS not too long ago. But my series would be incomplete if I didn't give it another mention. Old Dog New Tricks Expanding Salesforce's native rollup summary capabilities beyond just master-detail relationships is the core of DLRS functionality. But that's not all it can do. I've written about the rollup to relationship trick. Should also look through the great "cookbook" on the DLRS documentation site. There are all sorts of ideas for things you can do with DLRS that you might not have thought about. It Just Gets the Job Done Like the other tools in this series, DLRS is entirely free and it does what you need. What more is there to say?

  • Free Things I Always Install: Mopsy

    This is the second in a summer series of posts about free utilities I always install in a new Salesforce instance or that I install into existing instances once I come along to support them. I love free things! (These, by the way, are all free-like-a-beer.) Mopsy Mopsy is a replacement for the Today's Tasks component that is default on the Salesforce Home page. Today's Tasks Component Is Not Great Have you ever noticed that Today's Tasks just not that functional? For example, in this sandbox I created a task for myself that was due yesterday. Here's the Today's Tasks component: Phew! I'm thrilled that nothing is due today. Too bad it's not pointing out that I have a task that's overdue from yesterday. Using the carat in the upper right you can set it to show overdue tasks. But then it doesn't show tasks due today. (They're not yet overdue. Sigh.) Mopsy Fixes That I really only need one thing out of Mopsy and it delivers. Users can set it to show "Today + Overdue." There are actually quite a few additional filter options in Mopsy: But I am really after the option for Today + Overdue because it means my users are a little less likely to never finish those tasks from yesterday! It's also nice that Mopsy gives you a convenient button right on the component to make a new task. (It's that plus sign in the upper right.) I also like that the admin can set it to show some or all of the Comment field on the task. There are other features of Mopsy that you can explore. Like I said, I'm really interested in just the one thing. "User Selectable" Also Means "Inconsistent" One "gotcha" that applies to Mopsy the same as Today's Tasks is that the filter under that carat is user selectable. That means different users may set it differently and could, therefore, still miss tasks. There's no way for you, as the admin, to default Mopsy to Today + Overdue, and definitely no way to lock it there. So you'll want to train new users to set it and leave it alone. Right Tool If You Need It Your org might not use Tasks, or might use them sparingly. They can be handy as a To Do list that's tied to records and easily viewed by your colleagues. Tasks also have their drawbacks (which should probably be the subject of another post). But if your organization uses Tasks, then I recommend dropping Mopsy on your Home page so people can see what's coming up.

  • Free Things I Always Install: Lightning Messaging Utility

    This is the first in a summer series of posts about free utilities I always install when setting up a new Salesforce instance or that I install into existing instances once I come along to support it. I love free things! (These, by the way, are all free-like-a-beer.) First on the list (though it’s in no particular order) is the Lightning Messaging Utility from Salesforce Labs. “What’s Salesforce Labs?” you ask? To quote the AppExchange listing: Salesforce Labs is a program that lets engineers, professional services staff & other employees share AppExchange apps they've created with the customer community. Inspired by employees' work with customers of all sizes and industries, these apps range from simple utilities to entire vertical solutions. Salesforce Labs apps are free to use, but are not official products, and should be considered community projects - these apps are not officially tested or documented. Basically these are free apps that someone at Salesforce developed for a demo or in their spare time and they’re releasing them for us to use. That’s pretty cool! Labs is also the program that publishes Open Source Commons apps like DLRS. There are dozens of other tools out there released under the Labs program. I encourage you to try them out—and let me know if you find something amazing! Lightning Messaging Utility This is a simple app that does one thing and just makes it easy: LMU allows you to display messages on your Lightning pages that fit the Salesforce Lightning Design System and, therefore, look like they belong. I think it’s great that you can insert a rich text component onto a Lightning page and use it to display a message to your users. And you know I do it with emoji all the time! Or you can use a screen flow component and dynamically generate all kinds of informational messages, even if you aren’t using the flow for interactive screens. But when those are on the page they don’t quite look like the rest of Salesforce. I’m sure I could work at it to make these look a little closer to the rest of the page if I really understood graphic design principles. But I know it would still be just a little “off” no matter how much time I put into it. Depending on the use case, that might be OK. But often I want a simple message that should blend seamlessly into the rest of the design. It just makes things look more professional. That’s where Lightning Messaging Utility comes in. Here’s an LMU flag indicating they’re a current board member: Or a mentor Much better than Rich Text, right? Here’s a reminder for opportunities that don’t (yet) have products added. Sometimes you want to make it clear this was a major gift: Those examples are just taking advantage of LMU’s color options and the Lightning App Builder’s native conditional display of components. The possibilities are endless! Other Tricks One nice thing LMU can do that it’s very hard to do otherwise is display a pop-up window (a “toast” message). There are few ways to build pop-ups in Salesforce and sometimes you just wish you could force your users to pay attention. (Use sparingly.) LMU can also insert icons from the Lightning Design System. That gives you additional options beyond emoji, not to mention that those options all share the look and feel of the rest of Salesforce. Or you can mix and match emoji and SLDS icons, of course. How To LMU is free, so you’re going to get what you pay for. In LMU’s case the downside is documentation: You get a slide deck. That’s not ideal, so you might need to do a bit of futzing around. But this is a simple tool, you’ll figure it out!

  • Apsona: The Golden App for Bulk Data Operations

    If you’ve ever been in a conversation with me about my favorite apps or my Go To tools, you’ve heard me mention Apsona for Salesforce. I consider it so important that I require my clients to install it and maintain licenses as part of my contracts. I don’t want to waste their time (or mine) futzing around with other options for data import, export, and update. And despite a name that literally means “the golden app,” Apsona is not expensive at all. Let’s take a look at this little gem. The Apsona Tab When you click on the Apsona tab you get a “Salesforce inside Salesforce” interface where you’re going to interact with your records like a series of spreadsheets or list views. Apsona certainly has the ability to act on single records—including within the Apsona interface—but other than editing single records in a list view once in a while, that’s not what this is for. Apsona is your one stop shop for mass data operations. My Favorite Feature If I had to mention just a single feature of Apsona that puts it hand and shoulders above the Dataloader (or, it would be this: You can copy/paste the data you want to import rather than needing a CSV. That alone saves me hours in a year. Think about it for a second. Excel always seems so surprised! when you select to save something as a CSV. You get a dialog box forcing you to confirm that’s really what you want to do every single time. (In fairness, it probably wouldn’t be. But Dataloader can’t handle anything else.) Apsona goes the extra mile to accommodate you. You don’t even have to save your sheet. You can copy several columns or the whole sheet, and then paste into a box in Apsona to do your import. (Works from Google sheets too, of course.) Bam! Fast Bulk Updates The other thing I use Apsona for all the time is its incredibly efficient interface for bulk updating records. Filter a list of records and it takes just three clicks to mass update a field (or fields) on those records. Super handy if you’ve just added a new field, updated a picklist value, or have to clean up a bunch of records. For example, what if you have 20,000+ contacts that have a value in Work Email but nothing in Preferred Email and you want to start encouraging users to utilize NPSP’s three email fields the way they were meant to be used. Simply make a filter for Preferred Email = null, they click Update All, select Preferred Email, and select Work. Apsona will churn through the records in a couple of minutes and you’re done. You can bulk delete records just as quickly. All I can say to that is, “With great power comes great responsibility.” 🕸️ Super Fast Export Probably next on my list is the ability to export records with just a couple of clicks. Not that I want you working outside of Salesforce that often, but we all know sometimes it’s necessary. Great for backups, too. If you’ve made yourself a tabular view, Apsona is smart enough to suggest the columns in your view for export. And then you can add additional columns just by checking a box. Columns on related records are also available. Click Export and you have a downloaded CSV in seconds. Other Features Apsona gives you a quick and easy way to make new list views and filter them and then it shows you the full record count. Since standard Salesforce list views don’t give you the total count and SOQL requires you to remember all the API names of fields, this makes Apsona almost always the fastest place to answer questions like “How many contacts don’t have a value in Ethnicity?” or “How many opportunities have a close date in the last fiscal year?” Working with Apsona you’re also not tied to page layouts the way you are in the regular Salesforce UI, which can be handy at times. Similarly to working in reports and list views, Apsona gives you the option of seeing fields that aren’t on the page layout or narrowing down just a couple of fields that you want to see at a time. Apsona respects user permissions so nobody is getting edit or delete access through Apsona that they wouldn’t have otherwise. And you can even set different configurations within Apsona by profile, so that some people might only be able to bulk edit certain objects or fields, depending on how you are doing things in your org. By the way: When you’re doing those mass operations Apsona defaults to batch sizes of 200 records at a time. But it’s very simple to lower your batch size if you’re running into problems. Sometimes I even set it down to five or even one at a time if an import failing due to timeouts (often caused by the NPSP triggers). Yes, the look is circa 2008 You’ve probably noticed from the screenshots that Apsona’s look and feel is a little…dated. What can I say? It’s functional and data-dense (translation: “That font is very small.”) but maybe not as lovely as it could be. I believe they’re working on an update. When that comes, I’m sure I’ll have gripes about not being able to find things anymore… Price I don’t feel bad requiring my clients to purchase Apsona because it’s a great bargain. For nonprofits it’s just $435 for three users, $145 each additional user. If you’re a tiny nonprofit (annual gross revenue not exceeding $250,000), Apsona donates three licenses for free. That’s part of the company’s commitment to nonprofits and the Salesforce community that I particularly appreciate. Most orgs will only give Apsona licenses to admins and power users, so you are probably looking at less than $1,000/year. The time saved pays for itself! Nice People The last thing I’m going to say is that Apsona is just made up of nice people. Their commitment to nonprofits is genuine, all are helpful and quick to respond, and they’re just lovely to hang out with. What more could you want?

  • Rollup to Relationship: A Cool DLRS Trick

    I’ve already written about DLRS, or Dolores, one of my favorite free tools that gives you rollup summary superpowers. Today I want to tell you about a cool trick you can do with DLRS that kinda’ isn’t a “rollup” at all. Most of us, when we think of a “rollup summary field,” start thinking in terms of math operations like average, or count, or min, or max. Makes sense. If you think about rolling up information about a group of related records (also called “child” records) onto one that they’re all related to (the “parent”), those are the main uses. I could count the number of support cases that go with an account. Or I could count the number of sessions a student was late for, then count the number of total sessions, then divide the former by the latter to get an attendance percentage. Or maybe I want to sort through all the memberships a family has purchased and roll up the date of the most recent one to know when their membership is going to expire. Or you could count the number of memberships that family has purchased over the years… But here’s some outside-the-box thinking: You can make a rollup summary field that itself creates a special relationship to just one of the child records. (I know it’s generally frowned upon to single out one of your children for special treatment, but…) Perhaps your database tracks a price each year: Campbell Scholars Program wants to be able to give solid college choice advice to their students. So they want to know the tuition cost of any college or university their students are applying to each year. PA Virtual Charter School is paid by school districts for each student enrolled. But districts have different rates from each other and those rates (of course) also change each year. In each case we have a custom object,Tuition Cost, that holds child records to Account (representing the college or the school district). For each account for each year there is a tuition cost record. (We also know that there must be just one for each year, so we take other steps—that I won’t outline here—to make sure there is only a single record per account per year.) We have a “year” field on that record that is either itself a date field or it can be translated into a date by a formula field. It’s now very easy to make a DLRS rollup that finds the last tuition record ordered by the date field. That’s not where the magic comes in. The magic is what we’re doing with what we’ve found. We're not looking at a number field (like the tuition cost) and doing math on it. Nothing of the sort, in fact. We take the Id of that record and we put it into a target field that is, itself, a lookup relationship field. In the Salesforce user experience when you see a lookup field it shows as a link to the related record. But under the hood that field actually holds the unique Id of the related record, which is 15 characters of text. So by using DLRS to put an Id in that field, we have actually created a relationship–a link to the “most recent child tuition rate.” Once you have a relationship field like that, you can make formulas that span that relationship. That means that if a Campbell scholar is interested in a particular school, as soon as we create a college application record (to track that interest) we can show the school’s current cost just by putting a formula field on College Application. When PAVCS wants to generate an invoice to a school district, the invoice record (child to school district) already knows what the current tuition cost is for that district. I think that’s very cool and there are lots of ways to use it. Can you think of nifty examples in your org?

  • FormAssembly’s Price Increase

    It’s been a couple of months but I haven’t had a chance to talk about the fact that FormAssembly has raised their prices. By a lot. It makes me sad. And I think they should be ashamed of themselves. I’m saying this as someone that is still a huge proponent of FormAssembly and while I continue to be a FormAssembly partner and likely to recommend it when clients are looking for a form tool. I don’t get anything personally as a FormAssembly partner. Other than access to the partner site (which I basically never used in the past, but now have to use to find the prices), the benefit to being a partner is the ability for clients I refer to get a discount on their pricing. I assume those clients could negotiate essentially the same discount on their own if they worked at it, but I can save them a step. Given the inflation of the past couple of years and the reality of the marketplace, I’m not actually that surprised or concerned when prices go up in the normal course of things. My own consulting rates go up, for example, and I don’t apologize for that. (I like to think I also give more value with each passing year as my knowledge grows, but maybe that’s another blog post…) But FormAssembly has basically tripled their pricing for nonprofits. I suppose a small caveat is in order: FormAssembly for anyone with a current account is not going up in price. They are all grandfathered at their current pricing and feature level and FormAssembly has said that is “forever.” [Surely it can’t be forever, but it’s at least for the foreseeable future.] Opacity To make matters even worse, they’ve also made their pricing less transparent. Wait–did I say “less transparent”? They’ve made prices practically a secret. They don’t seem to realize just how much that skeeves out nonprofit people and will hurt their business among this community. Not that long ago you could go to the FormAssembly website and find a nice clear pricing page that showed about four tiers you might choose among with their costs in black and white. Now all you see on the “pricing” page is links to start a trial, get a demo, or compare features. If you’re anything like me, it feels uncomfortably like this is going to be an experience like buying a car. Blech. 🤮 It’s slightly better for FormAssembly partners because we can log into their partner site and actually see something resembling a pricing grid. I’ve pushed them hard to make that grid available publicly. I think they’re concerned that the pricing is now confusing so they don’t want to make it public. (They’re right that it’s confusing, by the way. But I still think transparency is better for business, particularly among the nonprofits that have always been strong champions for FormAssembly.) I should note at this point that FormAssembly’s competitors are equally opaque about their pricing, so the transparency issue isn’t my main beef. What I’m really concerned about is that FA has become so much less affordable. What Does It Cost Now? I noted, above, that FormAssembly doesn’t want to make pricing transparent because they’re concerned that it’s confusing. I think they are afraid that potential customers will be scared off if a higher bottom line is the first thing they see when they might be comparing FormAssembly with a lot more features to a competitor’s tool at a bargain basement price that can’t do any of the amazing things FA can do. OK, I can understand that fear, I’m just not that sympathetic because at an apples-to-apples level the rise in FormAssembly cost is still outrageous. In one of my very first posts I noted that I recommended clients get FormAssembly’s Premier level (now discontinued). Premier for nonprofits was about $1,700/year but was worth it because of the amazing prefill connector. In FormAssembly’s new pricing structure, if you want the same features that most of my clients use you’re going to have to pay more like $5,000 per year for their Essentials plan! I’m actually of two minds about that: I think it’s an utterly absurd price rise, not to mention a pretty steep annual cost. I still think it’s probably worthwhile for a whole lot of nonprofits. My clients that already have grandfathered prices are probably getting that level of value out of FormAssembly with the prefill connector. Complexity in Pricing If we want to get into that complexity that FormAssembly thinks you might not be able to handle, Essentials comes with a few features that Premier did not, such as Dynamic Picklists and multiple users on your FormAssembly account. So from FA’s perspective they’re providing more value. But other features are á la carte. So, for example, you’ll have to pay $600 more per year if you want credit card processing, which was included in Premier. In fact, the Salesforce connector is already an add-on to Essentials, but I’m counting it in the baseline because from my perspective a form tool without a Salesforce integration isn’t very useful. (See also: Google Forms.) Dynamic Picklists and multiple FA Users are features with which I have a love/hate relationship. (That’s a topic for another post.) But suffice it to say that I’m not sold on paying so much more to have those features, at least not with their current challenges. Essentials is not the cheapest FormAssembly plan. You can get as low as $2,800 for “Basic” (with a nonprofit discount—there is no additional partner discount on Basic). Basic, of course, does not have the prefill connector (not even as an add-on), so you lose what I always think is special about FormAssembly. Basic also doesn’t allow CSS, so you probably can’t make your forms look as branded as you would like. (They won’t be as ugly as Google Forms, but that’s a low bar.) In my opinion they have crippled Basic enough that you might be just as well off with another form tool. What Do I Recommend? It’s a whole lot harder now to know what to recommend for a client that’s just looking at getting a webform tool. I think I still come down on the side of FormAssembly, but it’s much less of a slam dunk at four thousand dollars than it was under two. If you are going to have more than just one form and you know your forms are going to get a lot of use, then the prefill connector is going to allow you to do things to reduce duplicates, improve your users’ experience, and save you money in the long term. In that case, FormAssembly Essentials will be worth it for you. Even without prefill, FormAssembly’s connector after the form is submitted can do a lot more than just insert a single record into Salesforce. So Basic might be worthwhile because I assume FormAssembly priced it to compete with the others in the marketplace. But there are other form tools to consider, some cheaper than FormAssembly, that may be able to do what you need. If you have only basic form needs, you probably have a lot of options to sort through. (The nonprofit Salesforce community is working on reviving a project to help with this kind of decision. But that effort is not at fruition quite yet.) There is also the possibility of using a screen flow exposed on a public Site that has gotten a good amount of discussion in the community recently. I think the complexity of building and maintaining this puts it out of reach for most organizations. But if you’re that organization that was just going to have a single form, it could be worthwhile to invest the time in building this and then have something that is completely free. Even if you have to pay a consultant to change or maintain it every so often, that’s going to be cheaper than a recurring form tool cost. I guess the best I can recommend is: It depends.

  • Always Build in a Sandbox. (Except When You Don't. Or can't.)

    It’s a mantra oft-repeated: “Never build directly in production.” If you’re an admin you should be building new automation, new objects and fields, or otherwise messing with your metadata only in a sandbox environment. And I agree. I regularly admonish my clients and my mentees to build only in a sandbox and to test thoroughly before deploying to production. It takes extra time but it’s an important safeguard. And yet... I’ve already argued that keeping some test data in production makes sense. I might as well lose the rest of my credibility right now: There are times to build directly in production. Honestly, we all do it. Except in the strictest and most regulated organizations/industries, it’s not even that uncommon. Sometimes “building” in production is reasonable, or perhaps even necessary. What Constitutes “Building” Anyway? I don’t think anyone would argue that it’s wrong to make a new report directly in production. [Would you???] It’s already a constant battle to get users to learn to edit and build their own reports. If you’re going to insist they be built in a sandbox you’re mandating that reports are only built by your Salesforce admin team. I believe in teaching my users to fish. Of course anything one might say about building reports is going to apply to dashboards as well... I can see an argument that reports and dashboards fall into a strange gray area where they, themselves, are metadata but they’re so dependent on data that maybe they’re a different category. Plus reports and dashboards are about showing the data that’s in the org, they’re not automation, or changes to the user interface, or the like. But the Lightning Report Builder has the ability to make row-level formulas. (In the past that would have required an admin to build a formula field for a specific reporting need, so bring ‘em on!) If it’s OK to process a formula in the context of running a report, that seems a very short distance from actually creating a formula field, no? That's why I would say that creating a formula field directly in production seems fairly reasonable. [Brief aside: If you’re doing this, take steps to test and validate before you let users see the new field: Uncheck the box that adds the field to page layouts. Maybe restrict field level security until it’s ready. You can look at the field in the meantime using a report. And note that modifying an existing field probably is a category of its own because that has potential spillover effects. Then again, if you find that a formula field is broken, I’d say working on a fix directly in production is fairly reasonable.] Here are a bunch of purely metadata modifications that I’m going to argue are safe to do directly in production: Edit page layouts and compact layouts Modify Lightning Record Pages Make a new Quick Action Those are all changes to the user interface but don’t impact data itself. Sure, depending on how extensive the page modifications are, you could confuse users a bit. Try to make things obvious or else give a heads-up. It’s OK to “move people’s cheese” as long as it’s still somewhere in the same fridge they last saw it. In the same vein, modifying a display-only screen flow should be safe. Or, for that matter, editing the display portions (only!) of a flow that also runs data operations. Go ahead and fix that typo you noticed. Similar to my argument for formula fields, I think you could make a new rollup summary (traditional rollup summaries, DLRS rollups, or NPSP Customizable Rollups). You’re going to learn more testing the rollup against the messy real data that’s in production than what you have to work with in a sandbox. As above: keep the field hidden from users until you've perfected it. And here's a good tip from Stephanie Foerst for a good time to build directly in prod: “When there's a production issue and you can easily resolve it.” Modifying Metadata in Production So we’ve determined that the difference between “data stuff” and metadata is not going to provide a bright line guideline. Sorry. If it’s a matter of degree not type, I think we’re going to have to start considering the impact of your actions. I know: Bummer. Considering the consequences of our actions is sooooooo haaaardddddd. If you’re going to modify metadata directly in production—and I think we all know you are—the best advice I can give is to think about when it’s OK and when it’s not. Ask yourself: 1. Is it gonna break stuff? Things that can break stuff include: Validation rules They don’t just stop users from getting things wrong–they stop integrations and Apex code, too. Automation But here you really have to consider what the automation is doing. 2. Is it going to escape the environment? Anything that sends an email. Integrations (though sometimes you don’t have a sandbox option on the other end of the integration) 3. Do I need to do a lot of testing that will result in records users might stumble upon? New integrations Automation (again) 4. Am I building new and/or self-contained functionality? New object? I would normally say that a new object is so self-contained that it makes perfect sense to build in a sandbox. But I asked around and others were pretty OK with building new objects in prod exactly because they are self-contained... New fields? Most of the time, work in sandbox. But just one field…? Go for it. 5. Experience Cloud I feel like this is almost a topic of its own (that should be written by someone that knows Experience Cloud/Communities better than I do). It’s a pain to deploy a built out Site from sandbox. Making changes in prod (but waiting to publish them) is pretty common. 6. [Special Case] Record Types This is a very specific use case that Peter Churchill pointed out to me: If you create a record type in production “they maintain their Ids in each environment, but Sandbox to Prod will create a new Id.” Sometimes it’s easier to build automation based on record type Ids, so this will save you some hassle. Personally, I prefer to have my automation look up record types by API name rather than rely on the Id being constant. Don’t Punk Yourself! Here’s the thing about making any modifications in production: They’re not likely to flow down into sandboxes—you’re going to forget to do that. In any environment where there is simultaneous development happening in sandboxes—even if you are the one doing the building in both environments—if you make a modification in production there’s a chance of undoing your work later when you deploy from the sandbox. Say I have an active sandbox named “mbkdev” where I’m building a child object to contact. In that sandbox I modify the contact page layout to add the related list for this new object. I make no other changes to the contact layout. My work in this sandbox is taking some time, so I haven’t deployed my new object and contact page layout yet. Meanwhile, I get a request for a formula field on contact to translate from Birthdate to display the contact’s age. (I know, you probably forgot there isn’t a standard field for this!) This is an eminently reasonable request and one that I want to deliver quickly. So I throw together the formula field and I drop it onto the page layout. While I’m at it, I decide to move demographic fields together into their own tidy section. Three weeks later we finish testing the work in the mbkdev sandbox and we’re ready to deploy our new object. Since we modified the contact page to include the new object’s related list, we put that layout in our change set. But the Age field doesn’t even exist in mbkdev and the demographic fields are in their (haphazard) positions from the moment the sandbox was first created. As soon as our deployment goes live, the contact layout has reverted to its state from three weeks back, with only the addition of our new related list. Oops. I’ve just undone my own work. How foolish do I feel? [This is a purely hypothetical situation. I have never allowed this to happen IRL.] It’s a challenge to keep sandboxes in sync. If you have deployment procedures, use them.

  • Setting Up the Free Integration Users

    A couple of weeks ago I was excited to write about the free integration users that Salesforce has granted to all organizations. As of that writing the licenses were still rolling out, so nobody had really had a chance to use them. Now that they’re available, there’s been a great deal of discussion/confusion about how to actually make them work. If you wade through the Trailblazer Community thread in that link, you can figure it out for yourself. But I thought it would probably be helpful if I wrote up clear instructions. As it turns out, the free integration user licenses are free like a beer. But it’s like they’re a beer bought by your high-maintenance friend. Perhaps after you’ve helped him assemble Ikea furniture. Or helped him move. Or both. That is to say, it’s a bit of work to use these free licenses. The steps you have to take are: Create a user with the Salesforce Integration user license and the only profile that you will have an option for once you have selected that license: Salesforce API Only System Integrations. (Or modify an existing user to have this license and profile.) In that user record, under Permission Set License Assignments, assign the Salesforce API Integration PSL. (I do not understand what a permission set license is or does. But without it you can’t assign a permission set in step 3 that grants the access you are going to need. I know you have to do this because of the Help article about the integration user licenses.) Create a permission set (or permission set group) that grants access to the right objects and fields. Assign that permission set to the user. That sounds pretty simple in black and white right there. But Step 3 is going to feel like assembling the worst Ikea project ever. Permsets are the Future What makes using the new Salesforce Integration user a challenge really comes down to the fact that integration user licenses come from a future in which permissions no longer reside on profiles. So you have to assign a permission set in Step 3 or else the integration user can’t access any objects or fields. But you and I don’t yet live in Salesforce orgs where all permissions are granted via permission sets ("permsets"), so we don’t have a permission set ready. In January 2023, Salesforce announced, via a blog post from Cheryl Feldman, that permissions on profiles will “end of life” at the Spring ‘26 release. We’ve known for a couple of years already that permission sets and permission set groups were the future of user management but Cheryl’s announcement put a deadline on the transition to focus our minds. The simple summary of that transition is that in the future every user will have a profile that grants basic login rights and a small handful of deep system privileges but all permissions related to object and field visibility will be layered onto users via permission sets. (Probably, users will get one or more permission set groups, which allow you to group permsets and then grant them all to a user at once. But it’s easier to discuss just in terms of permsets.) This is a better way to be able to manage user access by the principle of least privilege, in which you only give people access to those parts of Salesforce they need to do their job. Most organizations today, particularly the smaller nonprofits that I’ve worked with, have a couple of profiles that grant wide permissions. Even if they are given different profiles, program users and development users can see all the same objects and fields. The difference in the profiles may be that their page layouts or app defaults are different, but fundamental permissions are the same. Honestly, I suspect that most organizations probably use just a single profile (other than sysadmin). And for most of the rest, that have two or three profiles, a side-by-side comparison would show very little difference between them. It’s just rarely worth the effort to make the profiles very different in a small org, as there’s most people will need to see both program and development data. Since users can have only a single profile, what would you make someone that needs to see both program and development data? (Please don’t say, “We just make them a sysadmin.”) You would need either a “program and development profile” or you would have to manage both the profiles and some permsets for granting the other set of permissions. There just isn’t enough time in the day to put a ton of effort into ensuring that we have profiles with minor differences in object and field permissions. And as of right now, Salesforce is still mostly built to accommodate using profiles as the main differentiator. Permsets have existed for a while, but they’ve generally been secondary to profiles that have the bulk of permissions. (For example, when you install from the AppExchange the installer offers to "install for all profiles," with no options relating to permsets.) Even if you want to be forward thinking about using permsets, it’s still a little harder to manage. That was my long way of saying that in my experience most orgs manage user permissions through profiles primarily, if not exclusively. Even those of us that are interested in moving toward the future probably have only taken baby steps along that path. Licenses from The Future So, back to the free Integration User licenses. It’s not really just the licenses that appeared in orgs last month, there is also a profile to go with them, called Salesforce API Only System Integrations, which is the only profile you can assign to the integration user. And this is a profile from The Future: It can’t have object permissions. If you clone that profile and try to add, say, Read and Edit on Accounts, you’ll find that object settings for Account simply aren’t there. The new Integration User license can only take the Salesforce API Only System Integrations profile and that profile can’t be given access to any of the objects and fields you need it to see. That’s because, like I said, it’s from the future. (Just be glad it’s not here to assassinate us to prevent a future rebellion.) Fortunately, the user profile from the future can be granted permission sets. So all you need is a permission set that grants access to the objects and fields your integration user is going to need. Depending on what that integration user does, that might be a short or a very long list. If I’m setting up the integration user for a form tool, for example, I expect that it’s eventually going to need access to most, if not all, of the same objects that power users need. Just think about it, I could make a form for: Donations, which, depending on the complexity of the need, could require access to Account, Contact, Opportunity, Payment, Campaign, Campaign Member, GAU, GAU Allocation, Product, Pricebook, Task, User (to assign the task) and probably several more. Program Registration, which would require access to our custom objects for Program, Enrollment, etc… Surveys, which would require access to Contact, Survey, and possibly several more. So you can see that for some integration users you’re going to need a permset that grants a lot of access, as much as (or possibly more than) some users need. Even if you are super-conscious of security and only add iteratively to the form tool integration user’s permissions as you build each form, the final result is going to be a pretty extensive permset. And it's probably not one you already have. Prepare for the Future Today So we have the reality that at least one of your integration user’s permissions are going to be quite wide. Let me add the other consideration that a whole lot of orgs today have integrations logging in as sysadmins (either an integration user on a sysadmin profile or—worse!—sharing the login of a person who is a sysadmin). I would, therefore, argue that anything we do to grant permissions to the integration user granularly is going to be a security upgrade, even if “granularly” still starts from a large pile of permissions. So as you set up your permission set to make the integration user work, think about it as preparing your org for the user management regime of Spring 2026 and beyond. That means you’re going to make a permset for the integration user that serves as the foundation of your permset for human users. Permission to Build in Production [Temporarily] Granted I think I’m pretty consistent in reminding people to only build in sandboxes, never directly in production. (Though I also am realistic and think there are certain changes that it’s perfectly reasonable to make directly in production. I should probably write a future post on that...) Unfortunately, you simply can’t realistically work in sandboxes for this purpose because of the way profiles and permission sets deploy. When a profile or permset is deployed via a change set (or other deployment management tools), the only parts of it that actually deploy are those that relate to the other metadata that is deploying with them. That’s pretty interesting, if you think about it, because it means that Salesforce doesn’t just deploy a file for the profile or permset, but actually compares what it’s uploading to what is already there and only edits inserts, leaving the rest of the file alone. This interesting functionality supports deployments coming from people working in different sandboxes. If it didn’t work that way, for example, then Jodi would deploy her new custom object, Cars, and a modification to the Program Manager profile granting access to Cars and its fields. An hour later, when Aaron deploys the flow he’s been working on (in a different sandbox) that works with fields only on Contact and Account, his Program Manager profile is coming from an environment that doesn’t have Cars. Aaron’s deployment would overwrite what Jodi deployed, removing access to Cars for the Program Manager profile. So it’s usually quite handy that Salesforce deployments of permissions relate only to the metadata that comes along. But if you are trying to build a permission set that grants access to all objects, all fields, all tabs, and all record types, you would have to build up a change set that also includes all of those things. First, good luck ensuring that you get every relevant object and field into your change set without missing something. Second, the changes you send with all that metadata may overwrite or revert things that have changed in production and are out of sync with the sandbox you were working in. (I know you should have procedures for deployments to avoid that kind of overwrite, but it’s a lot harder to ensure it doesn’t happen when we’re talking about every object and field, which includes all descriptions, all help text, etc.) Copado Essentials, formerly ClickDeploy, my deployment tool of choice, has a “profile only deployment” option. As I understand it, that means that you add all the other metadata to your deployment to indicate the parts of the profile to send. But when it actually is sent, it’s only the profile that moves over. Interesting. But there is no such thing as a “permission set only” deployment. I hear that Gearset has the ability to do a permission set only deployment, but I couldn’t figure out how. I don’t think Salesforce’s native Change Sets allow for either of these options. Besides: Have I mentioned my skepticism that you would manage to add all the relevant related metadata to your change set without missing something? Copado Essentials makes it pretty easy to Select All and I’m still paranoid that something would be missed. Adding all the metadata into a change set via the native Salesforce change set tool is too painful to even contemplate.’re going to build your new permset in production. Building the Standard User Permset Now I have bad news for you: It’s going to take hundreds of clicks to build out your permission set. Maybe more than a thousand. If you work in just one org, at least you can take comfort in only clicking hundreds of times once over. A solo consultant like me gets to do it for each of my client orgs. Ouch. Worse yet, I determined that you have to do this work directly in production the hard way. By “the hard way,” I mean that I did the hundreds of clicks in a client sandbox, with the intent of testing that the integration user had all the permissions it needed before I moved to production. Then I found that I couldn’t deploy the permset and had to hand rebuild it in their production org! Double ouch. Hopefully sometime in the next few years Salesforce will put out tooling that makes this easier. (I know that Cheryl Feldman and her team are already working on some of it.) But unless you want to wait for better tools before you use the integration licenses you’re going to have to go through this pain now. (And having done so, you might not even need the better tools later. Womp womp.  😞) As noted above, I think at least one of your integration users is going to need similar permissions to a standard user (or possibly a little bit more), so I’m going to write these instructions on the assumption that you are building out a single base permset that actually has quite a lot of object and field permissions. If you have only integrations that have limited permission needs, you should build them very limited permsets (again: the principle of least privilege). But if you have at least one integration user (like your form tool) that needs a lot, this is the time to build a wide baseline permset. It’s easier to clone that permset and edit down to make less-privileged versions later. Here’s what you need to do: 1. Make a new permission set. (Setup>Users>Permission Sets>New) You can call it something like “MyOrg Standard.” I always recommend a Description. (Help Future You remember how this permset is used.) Do not associate it with a license type—leave that picklist blank. 2. In the permission set, go to Object Settings. (I’m assuming you’re using the Enhanced Profile User Interface. If you are not, go immediately to Setup>Users>User Management Settings and move the slider to Enabled. I don’t know how anyone works with the classic profile/permset editor!) Here you will have a list of all the objects in your org. (You'll also see a bunch of things such as “App Analytics Query Requests” that are listed as objects but maybe aren’t quite? I don’t understand it. Just ignore those.) 3. Open one of the objects, perhaps in a new tab. Let's take Accounts as our example, since it's at or near the top. This profile is going to need at least Read access for every object the integration user might touch, including Accounts. Given that the integration probably inserts and/or updates data, I think you probably want to grant Create, Read, and Edit (“CRE”) for each of those objects. (Most integrations and most standard users probably don’t need to delete, so we’re not going to grant that permission.) You are also going to need to grant edit for most fields on each of those objects. And for those fields that aren’t editable (like formula fields) you need the integration user to have read access for that field. This is where the enormous amount of clicking comes in, as there is no Select All button. Sigh. [And to make things worse, the field level security boxes are tiny and low contrast, so it’s hard to tell which Edit boxes are grayed out and which you want/need to click. It's hard enough for me. I have no idea how people with vision problems are able to use this interface.] I’m going to be honest here: I just checked every single box on every single object. In theory I should consider the purpose of each field and decide whether this permission set needs read or edit access to it. But that would take forever. It’s just not reasonable in this context. It’s one thing to carefully consider field level security by user persona as you create a new field or three, but it’s exponentially more difficult when you are talking about all fields on all objects at once. 4. Don’t forget to also give visibility into the object’s tab, if applicable. Admittedly, the integration user probably doesn’t need the tab visibility, as it doesn’t use the UI, but I think it’s worth the click now, while you’re already here, in order to make this a permission set you can use for people in the future. 5. Similarly, assign all record types to this permset. Again, any given integration might need only one or two record types, but if this is going to be the basis for a permset used by humans later, they’re probably going to need them all. Save clicks later by making this The Big Full Access Permset. It will be easier later to narrow things. 6. When you’ve done this for every object your integration user (or future humans) might need, you can stretch out your mouse hand and reward yourself. 🧁 My method was to open the Object Settings and option-click a dozen or so objects into new tabs. Then I went through the tabs clicking Edit on each. Then I worked my way down the line of tabs doing all the clicking, saving, then closing that tab. When I ended up back at the objects list, I refreshed, then started again from the bottom-most object that needed access but didn’t have it yet. You may want to listen to a podcast or music while you’re doing this mostly-mindless clicking work. 🎧 Pro Tip: Work on a permset that is not yet part of a permission set group. That will allow you to save much faster. Permsets that are in groups need extra time to process a save because the permset group also recalculates. I found that if my permset was in a group I couldn’t really work in different tabs because I was faster than the recalculation. Further discussion: I just described creating a single master permission set. In theory it would be better to create permission sets either for single objects or at least clusters of objects that go together for individual bits of functionality and then to group those into a permission set group. But as I think I’ve said multiple times, “Who has the time?” Building permsets up like that is great in theory and may be workable as you are implementing a brand new org, but it’s unrealistic when you’re talking about an org that’s already in use and a small Salesforce admin team. If you want to just get integration user licenses working, this is the baseline for how you can do it. It's Worth It This is clearly a ton of work to get set up the first time. But remember that you're laying the groundwork for a user management and security transition you have to make in 2026. Plus you're getting to use free integration users and save your paid (or granted) licenses only for people!

  • Tools I Love: DLRS (the Declarative Lookup Rollup Summary tool)

    Let me introduce you to my friend, DLRS, pronounced either “dee-el-arr-ess” or, my preference, “Dolores.” That’s not its real name. It’s really the Declarative Lookup Rollup Summary tool. I think it’s more fun to call it Dolores because it helps me feel closer to this amazing, free, and powerful resource. DLRS was originally created by Andrew Fawcett to fill some gaps in Salesforce functionality. 🎂 DLRS is turning ten years old this month! That's something to celebrate! DLRS gives you rollup summary superpowers that no nonprofit admin should be without. But before I get into the superpowers, let me help you with some DLRS context, like what it means: Declarative This is the easy part. In fact, what it really means is “this tool is for everyone, it’s easy to use.” Declarative means that something can be done with clicks, not code. So from the start, we know that DRLS is built to allow you to do things that before would have required you to write code. (Quick side note: With the incredible growth in power of flexibility of Flow you could accomplish most of the functionality of DRLS now with Flow, which is technically a declarative tool. But that ability comes from the fact that flow has grown to straddle the declarative vs. development line. I consider it more work to build and maintain rollups via Flow than with DLRS, so I wouldn’t recommend that route. More on that below.) Lookup Lookup refers to the fact that DLRS can perform rollup summary operations across a lookup relationship in Salesforce. This is a simple relationship between records, where one has a reference to the other. Without getting too deep into it right now, there are times when a lookup makes more sense than the tighter relationship of master detail, often known as “parent/child.” Master detail relationships are not generally “reparentable,” usually involve cascade delete (if the parent is deleted, so are all the children), and also have implications for Salesforce record privacy (anyone that can see the parent can see the children). Standard Salesforce rollup summary fields (“RUS fields”) can only be built across a master detail relationship. DLRS allows rollups across the less-close lookup relationship. Rollup Summary Out-of-the-box Salesforce can make rollup summary (“RUS”) fields that show summarized information about child records, such as counting them, finding the largest (MAX) or smallest (MIN), summing, averaging, or the like. RUS fields generate some of the most interesting insights about your data, such as number of people enrolled in a program, attendance percentages, number of people in a household, etc. OK, that’s what it means. But the most important thing to know about DLRS is that it gives you rollup summary superpowers. And those are powers you might want to focus on master detail relationships as well. 🔋 Powers DLRS Has that RUS Do Not Whereas standard Salesforce RUS fields are limited to count, sum, mix, and max, DRLS adds quite a few operations you might want to do, including the ability to concatenate text. Two of DLRS’s powers that I think are worth calling out separately: Relative Date Filters One of the most common things people consider making a rollup summary about is to have a relative date filter such as “this year.” Perhaps you want to count applications “this year” or purchases “last month.” You can do that in a Salesforce report easily. And you can include relative date filters in formulas as well. But you can’t filter the records you’re going to summarize in a standard RUS field with relative date language. Averages Standard RUS fields can count or sum, but average is not an option. This means that the out of the box way to calculate a rollup summary average in Salesforce requires the admin to build three fields. (One to count child records, one to total the value in the child records, and the third is a formula that divides the total by the count.) Obviously this isn’t the end of the world, but DLRS allows you to accomplish an average with just one field, saving time and effort. So even if you are dealing with rollups across master detail relationship, DLRS is a great addition to your toolbox. Why DLRS and Not [fill in the blank]? There are two other tools people often suggest to meet a similar need as DLRS. Rollup Helper Rollup Helper is a freemium AppExchange tool. Nonprofits can have up to three free rollups permanently with Rollup Helper. Also, being a commercial product, Rollup Helper has a user friendly interface and, like DLRS, it can work across lookup relationships and do more kinds of calculations. Honestly, I have nothing bad to say about RollupHelper. I just prefer to save money for nonprofits, so I’ll go with DLRS every time. Flow As I mentioned above, Salesforce Flow has become a very powerful tool, with most of the capabilities of code. It’s not that hard to build a record-triggered flow that loops through related records to summarize them. One major limitation here is that if you want results in realtime you will have to build at least two flows: one on create or update of a “child” record, and one on delete. As of now (and I don’t think there is any roadmap for change any time soon), record-triggered Flows can have either a create/update context or a delete context, but not both. I also think that building and testing a flow (or modifying an existing flow) each time you find a new rollup summary need is significantly more cumbersome than building a DLRS rollup. Things You Might Want To Roll Up 🗞️ If you aren’t already brimming with ideas of things you want to roll up using DLRS or standard rollup summaries, let me try to jump start some thoughts: If you have students applying to colleges (or high schools) you’ll probably want to know: - How many applications does this student have? - How many acceptances does this student have? - How many students have applied to this school this year? - How many applied last year? - How many were accepted/waitlisted/rejected this year/last year? If you rescue animals you might need to know: - How many cats/dogs/rabbits are at each shelter? - What is the average length of stay in shelter? - What percentage of animals are awaiting urgent veterinary care? If you train teachers, you might want to count: - Enrollments in your mentorship program. - Completed/incomplete mentorships. - Teachers at each school that have completed your program. If you raise money for environmental causes you might need to know: - How many donations have gone to each nonprofit partner? - How many unique donors have given to each partner? If you run a women’s shelter you’ll probably need to know: - How many times has a client been in shelter? - What is her average length of stay? - How many services did she access while in shelter? This list barely scratches the surface, of course. Your own program is going to determine the fields you need. If you want even more inspiration, look at the DLRS Cookbook, which has example rollups and instructions for building them. [Full disclosure: I helped write that cookbook.] One More Thing To Love: DLRS is now part of Open Source Commons Andrew Fawcett and a handful of helpers kept DLRS up to date entirely on a volunteer basis for many years. We all owe them a huge debt of gratitude! "This tool was initially a solution looking for a problem and in part a technical demonstration of the Metadata API," says Andrew Fawcett. "And wow did it ever find its place as a solution for many of its users! At its heart at the very start was a desire to continue to do what the platform does best: democratize capabilities—and that continues to make it so popular today." In order to ensure the continued development and support of DLRS, in 2022 Andrew asked if people could step in to take over DLRS. Now it's become part of the Open Source Commons program. That means this app has a formal structure to support it, expand it, and ensure that it will forever be free for nonprofits and anyone else that wants to use it. "Thank you everyone for your support and encouragement over the past 10 years, I cannot wait to see what it looks like in 10 more years!" - Andrew Fawcett I’m proud to volunteer my time for the DLRS project, helping with writing and editing documentation. It’s one of the ways I try to give back to the amazing community of Salesforce professionals that have helped me so much. Go Out and Try It! I hope I’ve convinced you that DRLS is a tool you want in your toolbox. Be warned: as with any tool, you’re going to have to learn how to use it. (Even wielding a hammer is not as simple as just grabbing it and swinging!) I think it’s beyond the scope of my blog to make this or a future post into a full scale How To Build Your First DLRS. But don’t worry—the DLRS documentation is extensive and the documentation team is constantly working to expand it! Need further help? Just ask in the Community Project: DLRS group on Trailblazer Community.

bottom of page