Search Results

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!

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.

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?

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.

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 salesforce.com 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 salesforce.com 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!

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 Dataloader.io), 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?

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.

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?

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.

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.

Raise your hand if you have fake or test records in production. 🙋🏽‍♀️🙋🏾‍♂️🙋 You, in the back—Really? You don’t have a single record that you use when you want to try out a new field, test an automation, or troubleshoot? Uh huh. Let’s get that hand in the air, then. 🙋 I’m not too proud to admit that I put test data in production. I even do it in my client’s orgs. I think that’s OK. No–I actually think it’s necessary. It’s Efficient I don’t see how you can efficiently get by without test data in production. Even when you are scrupulously meticulous about never building in production (And you are…right?) You’re going to have new things you’ve deployed that you want to see. You’re going to get users that have trouble and you need to quickly reproduce the issue And you’re going to have quick training and enablement moments that you want to take advantage of without having to go through the rigamarole of setting up sandbox data. So, yes, I do put test data into production. What Data It comes down to what data and how much data? I have two rules of thumb: Is it obvious? Is it fun? Clearly, the second one is optional. (But is it...?) If you want to have contacts Test Test and accounts Account1, Account2, and Account3, go for it. But remember that contact Test Test in the Nonprofit Success Pack is going to end up with a household account Test Household. I think there are people with the last name “Test.” It’s not actually obvious whether it’s real or fake, is it? Why not put Harry Potter in your middle school? (He should be enrolled at Hogwarts, of course.) Or set up King T’Challa as one of your young professionals. (He probably works for the Kingdom of Wakanda.) I suppose there’s some chance one of your users won’t get the joke. But it’s also possible there is a real person out there named First Last. (There are people whose last name is Null…) Easily Identifiable My point is that if you have these records you might as well be able to identify them. Plus you’re set up for success later on when you need to spin up a quick report or show someone how to make a related record. Working with test records that fit a theme makes it easy for you and everyone else to remember which are the fake records and filter them off reports or ignore them in list views. And you do want to filter them off 99% of the time. Get into the habit of adding a filter to every report that will remove your fake records, whether it’s donations from the T’Challa Household or students whose Primary Affiliation includes “Hogwarts.” Let your users know why you’re doing it as well so that they don’t fake themselves out when making their own reports. Have Some Fun I already mentioned that I use Harry Potter and Hogwarts. In fact most of my education instances have Harry, Hermione Granger, and Ron Weasley at the very least. (It’s a joke that can appeal to most ages.) The beauty of using those characters is that we also know their relationships with a bunch of other contacts and accounts we might want to work with, such as their parents, their teachers, and even some businesses and institutions. I don’t put that whole panoply of records into production but I most certainly like to use it as data in my training sandboxes! When I need some more students outside the Potterverse, but easily recognizable, I’ve turned to superheroes. The Marvel Universe is nice because you can find characters in a variety of age categories and still stay pretty obvious and mainstream. People might not have seen the latest movie in the franchise, but they’ll know the names Black Panther and Captain Marvel. More often than not people will even recognize their secret identities, if you want to use them. DC characters will work as well, if you’re into them, but you might choose to create Super Man instead of Superman because: Required Fields. Star Wars characters are fun, too. When I worked at Spark my Go-To kids were Luke Skywalker, Han Solo, and Chewbacca Wookie. (He had to have a last name: Required field.) Again, I figured I could be pretty confident nobody would think they were real students. And I had so much fun setting up their mentorships with Darth Vader and his colleagues at Death Star Demolitions Company. Contacts don’t have to get all the love, either! When my education clients need school and college records I have, among others: Idyllic New England Liberal Arts School (my alma mater) Big Southern Football University Ivy League University Metropolis University (also good for superheroes to attend) Hogwarts School of Witchcraft and Wizardry The Bronx High School of Science and Superheroes (Peter Parker’s alma mater) When we were creating the original package for Ombudsman Cloud Care we needed test and training data. Props to my wife, Jen, for taking the Navy theme to its logical conclusion. I’d originally created Popeye and Olive Oyl. Jen added several characters from Star Trek and The Next Generation as well as delightful Cases to go with them! That gave us some fun Easter Eggs for people to notice as they went through training. It’s not that I actually think it’s ideal to have test data in production. I just think there’s almost no way around it. So given that reality, let’s make it enjoyable!

⚠️ Warning: Cynicism ahead. I’m going to cut through marketing and spin to call it as I see it. (I hope you already were expecting that from me.) On Tuesday Salesforce.org announced the “New Nonprofit Cloud.” Lori Freeman also posted about the post in the Trailblazer Community. Here’s the TL;DR, IMHO: Over the next few years Salesforce.org is coming out with an entirely new technology suite of solutions for nonprofits. These collectively will be known as “Nonprofit Cloud.” These will not be based on, nor compatible with, the current solutions, including NPSP. You need not concern yourself with “Nonprofit Cloud” for the time being. Nonprofit Pricing does not change. (Ten free licenses, etc…) Except Nonprofit Cloud licenses cost more than standard licenses for your 11th and up. There is quite a lot to unpack about this announcement, not all of it actually included in the announcement itself. I think it’s worth making this a relatively long post to go bring all the parts together. Pricing In my opinion, the two important things that make Salesforce valuable for nonprofits are the Power of Us program (donating the first ten licenses free to nonprofits) and the additional discounts that apply to all other Salesforce product SKUs. This is not changing. Though I had been assured this would not change before TrailblazerDX, I still felt it was important to hold Salesforce’s feet to the fire. I asked a question during True To The Core, seeking commitment at the highest and most public level. (My question, followed by Parker Harris’ answer, starts at 21:20.) Parker’s answer, Lori’s post about today’s announcement, and other communications give me confidence that we can count on Salesforce’s ongoing support for nonprofits. (As much as we can count on anything a business may say or do.) Pricing after your free licenses is also not necessarily going to be simple, which may partly have to do with Salesforce.org’s inclusion under Industries. I don’t even know if Salesforce.org’s people know all the ins-and-outs of how the licensing–and, therefore, the pricing–works yet. What I understand is that Nonprofit Cloud will be its own SKU that, essentially, bundles a Sales Cloud license, a Service Cloud license, and something-that-gives-access-to-the-Industries-based-functionality. [I don’t know the right term for that thing. I don’t think the name matters right now.] All ten licenses granted to new orgs on the new Nonprofit Cloud will have that entire bundle. So in that sense, the P10 License Grant has expanded with this new announcement, as that bundle is more expensive than what we have been getting to date and comes with extra tech. (Yay!) For the 11th license and above, organizations will be able to choose what they want to purchase: Nonprofit Cloud licenses (the whole SKU bundle) will cost $720/year. A Lightning Enterprise Edition license (a “Sales Cloud license,” like we usually purchase today) is $432/year. (Neither of these represents any change to current pricing, by the way. What the Nonprofit Cloud SKU encompasses is changing, but the name and price stay the same.) The uncertainty that I mentioned is that I don’t know what functionality users with “just” a Lightning Enterprise Edition will be unable to accomplish compared to those on a Nonprofit Cloud license. By extension, I know even less what users on Platform licenses would be able or unable to do. We don’t know what “Industries” functions such users will lose, much less what parts of the as-yet-unseen Nonprofit Cloud application. The Technology News flash: What has just been announced is not yet ready for Prime Time. I know that you may be surprised to hear that an announcement of a new product from a tech company is not actually ready yet. 😜 You should not plan to migrate your current org to the new Nonprofit Cloud any time soon. There would be no immediate benefits and that migration is going to be a big undertaking. I fully expect most organizations to put it off as long as possible, upwards of five years, probably more. If your system ain’t broke, don’t fix it. If you are about to embark on a net new implementation, you have a tough choice to make: You can implement using NPSP, which Salesforce.org has committed to supporting, but is not being additionally developed and will eventually be “the old version.” You can implement the new Nonprofit Cloud, which will be version 1.0 at best, and might feel more like beta 0.9 for some time. You’ll be on the leading edge. (Or possibly the bleeding edge.) Or you can split the difference, implementing on Nonprofit Cloud but building much or all of your functionality custom. That might make it easier to adopt features as Nonprofit Cloud gets more mature. For now you’d be out of step with almost all other nonprofits using Salesforce, who are on NPSP. That’s not an easy choice. I’d be torn between one and three. To the extent that you can buy “it” yet, nobody’s really seen what “it” is. And when it actually comes out, it’s going to be a “minimum viable product.” This is going to be the first release of a new product from a software company. Some cynics might even refer to it as a “paid beta.” One can hope they’ll release a “minimum loveable product,” but I’m not going to hold my breath. What initially rolls out will be program management, then impact measurement, with fundraising not even being released until the fall. I think it’s safe to assume none of those releases will have full feature parity with their equivalent current products. (Though they should have some new cool features of their own.) And Salesforce has said that they are not planning a new payment processing platform (like Elevate.) I honestly just don’t know what to expect out of the actual Nonprofit Cloud product offering. It’s barely even available for anyone to get their hands on. There’s some way partners can get a learning org or… something… (I haven’t even tried.) Anway, as noted above, what comes out in the next few releases is going to be minimum viable, so I feel no urgency around it. (I’m sure I would feel urgency if I worked for an independent software vendor (ISV) that had an AppExchange product that I’d need to rebuild to be compatible with the new model.) The only thing we really know is that Nonprofit Cloud will use Person Accounts. That’s a pretty big data model shift, but it doesn’t bother me. I used person accounts for one project and thought they were fine. There’s a bit we'll all have to learn about how they work (always act like an account, sometimes like a contact) and they use a bit more storage (because every contact is also an account). But since storage was increased several years ago I don’t think this is likely an issue for most organizations. Also, person accounts are apparently the state of the art for things like Financial Services Cloud and have gotten quite a bit more love since Industries became a thing. I’m firmly planning to ignore Nonprofit Cloud for at least a year, probably two or three. Eventually I hope to look back and find that it’s grown up a bit and then I’ll start–only start!–thinking about adopting it. Timing of Announcements (what we knew and when) Full disclosure here: Lots of people–including I–did not just learn of this when it was announced on 3/14. Salesforce.org held embargoed meetings with Salesforce MVPs, partners, and presumably some larger nonprofit customers starting in late fall, 2022. (I assume there were people with better access than I have who learned things farther back than that.) Salesforce.org made missteps in the communication that caused a great deal of panic. First there were questions about whether the Power of Us donation would go away, or if some things would be no-longer free, or become more expensive, etc. Then there was the technical question of what would be compatible and worries over the cost that organizations will have to bear when/if they migrate to the new thing, not to mention uncertainty over whether or when they would be forced do so. The layoffs at Salesforce (that at least seem to have impacted Salesforce.org disproportionately, though no hard data is available on this) added significantly to the uncertainty and the anxiety. And, as you may have noted if you listened to my question from True To The Core, the absorption of Salesforce.org two years ago, the folding of the Power of Us Hub into the wider Trailblazer Community, switching technologically to using the Industries core architecture, a complete changeover to a new product, and then the layoffs, definitely opened the question of whether nonprofits are being viewed as “just another industry vertical” by Salesforce. I hope that all of my discussion, above, makes clear that I think those fears/questions have been laid to rest. I did not come to this level of detachment right away, so I think it’s OK for you not to as well. This was one of the most difficult NDA’d pieces of information I’ve ever held, mainly because it wasn’t so much “information” as the opening of a discussion that we were unable to actually discuss. I’m very glad to finally be able to talk about this openly! What Does this Announcement Signal About Salesforce.org? I have never thought that Salesforce–or even Salesforce.org–was some kind of altruistic actor. Read Marc Benioff’s books or listen to any one of his keynotes: That man is A Capitalist. I think he actually believes himself when he says, “business is the greatest force for good.” Salesforce is a capitalist enterprise, a multi-billion dollar corporation that exists only to make money. Do not kid yourself that it is anything else. (Capitalism would not allow it to be anything else. That's what the ism part means.) I applaud the 1-1-1 model and appreciate all that Salesforce does to support nonprofits. But I am under no illusion that this is anything more than noblesse oblige. I know that Salesforce.org used to be a “social enterprise,” but maybe I just came along too late in the evolution to be all that impressed by the term. At least by the time I was learning about it, Salesforce.org seemed to be a strange kind of hybrid creature that granted some licenses but sold others, had a sales operation that acted exactly like car dealers, and supported interesting events like Open Source Sprints but was completely opaque when it came to organizational structure and goals. So when .org was reabsorbed into .com two years ago, I mostly just shrugged. And it’s actually been quite interesting to see how being “internal” has clearly given better access to technology, decisionmakers, and even resources. (Sprints, for example, now take place in Salesforce’s offices, usually known as "Towers." That ensures a much better wi-fi environment than hotel conference rooms could be counted on for, makes single day events do-able, and gives us access to great free snacks and beautiful city views.) Salesforce.org built and supported some interesting technical products that have been good for nonprofits. They’ve also built some things my clients haven’t bothered to pay for. I’ve heard criticism that .org builds for the market of larger and better-resourced nonprofits that can pay for things. Well, “Duh!” (It’s amusing to me that some of the people leveling that particular criticism are consultants at medium or large consultancies that survive financially by working with those size organizations. Consultancies can’t make a profit working with the tiny orgs that are most of my clients, for example.) Nobody expects Ford to donate a Fiesta to any nonprofit anywhere in the world just for asking. Salesforce does the equivalent of exactly that every single day! Apple donates some hardware to schools, but that’s through a formal grant program, it’s not available to every school every year. Schools can buy through the Apple Store for Education at about a 10% discount. Salesforce gives ten licenses in perpetuity to any organization that can waive a 501c3 (or national equivalent) and then discounts 50-80% beyond that for everything else. Neither the automobiles that nonprofits drive nor the computer hardware they use are customized for how those nonprofits do business, at least not unless they pay for such custom work. But Salesforce.org gives nonprofits the NPSP/EDA/Nonprofit Cloud/Education Cloud to customize the platform for our needs. If only the Power of Us Grant and the discounts remained, I would still consider that a pretty great support of nonprofits. So long as Salesforce.org in some form is alive and kicking, creating software, supporting Open Source Sprints, bringing nonprofits and educational organizations together, etc, that’s a bonus that I am thrilled to benefit from.