Search Results
68 items found for ""
- Whiz-Bang at What Cost?
If you're like me, you're probably drowning in all the announcements from Dreamforce 2024 about generative AI (genAI) features under the Einstein and Agentforce branding. And you're probably asking yourself, as I am: "How much is this stuff going to cost?" These genAI features are going to be far from free. You're going to need the right kind of licensing and you're going to consume credits. Licensing The picture on licensing cost is starting to come into focus. Any user that is going to actually use genAI will need to have a proper license. Using genAI means sending a prompt to a generative pretrained transformer (GPT) and getting back results in the form of text, created or rewritten. Users that aren't the requester or the direct recipient of the AI answer should not need an AI license. Licensing your users starts with two options: Einstein 1 Edition This is a rebranding of Unlimited Edition, with Einstein for Sales/Service bundled (see below), Data Cloud (presumably with more credits than the free allocation), and some other things. ( You might recall how I feel about UE. ) With nonprofit discount these licenses are $3,600/user/year (down from list price of $6,000). So to summarize, my understanding is that if you're on Einstein 1 Edition then you pay for genAI features for all users, whether they send prompts to EinsteinGPT or not. Einstein for Sales (or Einstein for Service) This is an add-on license (probably a Feature License) that can be assigned to a user to enable genAI tools. It's my understanding that you can buy these add-ons only for the users that need them , which will save a lot of money. You're not going to need GPT for every person in your org, since some people will not send prompts. Your AE will probably imply that you should get one for everyone, but you should not . ( Spoiler Alert: AEs are Salespeople. ) The Einstein for Sales/Service add-on is $900/user/year at list price. As of this writing, I have not yet seen a nonprofit discount price. Since Einstein 1 Edition for nonprofits, above, comes to 40% off list price, I expect the nonprofit discount for Einstein for Sales/Service will probably be similar (so perhaps $540/year). [PS - I don't think there's really a huge distinction between the Sales or Service versions, they're naming that's meant to parallel the licensing naming. ( Don't buy both Sales and Service if you're a nonprofit!) ] Even if you economize as much as possible, it's looking like a minimum of more than $500/year to get AI features, for just a single user. Valid testing, let alone usage, is going to require at least the admin and one business user. That could become a significant additional annual cost to your "free" nonprofit software. By the way, with all the announcements leading up to and during Dreamforce, I'm writing this without a clear understanding of whether "Agentforce" replaces the "Einstein for" branding or if Agentforce represents something entirely new. GenAI Credits Once you've got the licensing in place, you're going to consume "credits." This is where I really can't help much with specifics. I'm not sure anyone can yet. First of all, I've asked around and have yet to understand which actions will actually consume a credit, or whether certain actions consume multiple credits at a time. If you read carefully in the nonprofit pricing guide PDF , you might have noticed that Nonprofit Cloud Einstein 1 Sales entitles you to "All features in Unlimited Edition plus Einstein for Sales (25K AI requests per user per month)..." I think that implies that 25K requests per month is also the allocation you'd get if you bought Einstein for Sales on its own. (But don't quote me on this.) Twenty five thousand AI requests per person per month sounds like it could be quite a lot. But is it? If the idea is to individually personalize fundraising emails to your entire list, that could soak them up pretty quickly if your list is large. It seems like it should cost a minimum of one credit per person on the list, since you would be asking EinsteinGPT to personalize to that potential donor. But at least you know exactly how many people are on your email list and how many email appeals you want to send. The other commonly-discussed use for GPT is for something like a customer service chatbot. A university might want to have a registrar's chatbot that can answer students' questions about course add/drop, or a comptroller's chatbot to help them make sure their student account is paid. Estimating credits for those use cases seems a lot less straightforward to me. I would assume a credit is consumed with each response in the chat. (Surely it's not just one credit per conversation.) Deploy that chatbot where a lot of people might use it (kinda' the point!) and you could start soaking up credits fast . We got at least one pricing clue in a September 12 press release from Salesforce. It's a rather long read for a press release, but at the very bottom you find, "Agentforce pricing starts at $2 per conversation; standard volume discounts apply." In some ways that generates more questions than it answers. Are "conversations" the same as the "requests" I was quoting numbers for above? Do you have to buy some bundle of conversations up front, or is it entirely based on usage? Does building and testing in a sandbox come free or still cost per conversations? What, if any, licensing is required to access Agentforce for Sales and Service? How will you know if you're going to get a huge bill? Plus doing a lot of this this might also require that you consume some (or many) Data Cloud credits at the same time...? Data Cloud Which reminds me: I've heard several references to possibly "requiring" Data Cloud in order to use Einstein genAI features. I have little to no understanding of what that actually means or whether you would need to have something beyond the free Data Cloud that every org is entitled to. I can see why this would be required if you wanted to combine your Salesforce data with data in other systems (email marketing, web click tracking) before you send it to EinsteinGPT. But I don't know if Data Cloud would somehow be required if you only want to use Salesforce data. If you have to purchase Data Cloud beyond the free allocation, my understanding is that it starts at $100,000/year! (Plus the cost of implementing, of course, which you're surely going to need a large consultancy for.) Nobody Knows 🤷🏻 Let me be fair to Salesforce here, though: I don't think they know how consumption-based pricing is going to work either. Their costs to provide these services to customers are consumption-based, because that's how cloud computing services are priced, whether genAI or elastic web storage. So they have to balance a massive uncertainty in how much their costs could balloon if people adopt these features. They're trying to offer the fancy new features that they think people want while figuring out the cost, pricing, and revenue models all at the same time. It certainly seems like the wave of the future for Salesforce costs will be more consumption-based and less fixed-price license based. But the actual outlines of that pricing are still pretty hazy.
- Freebie's Dreamforce Tips
I'll be presenting at Dreamforce in a couple of weeks, which I'm very excited about. [I hope I'll get to meet you there! If you're a reader, please say Hi. I'll even give you some stickers!] If you have never been to Dreamforce, it's quite...something. Over forty thousand of your closest friends, in packs of Trailblazer hoodies , taking over the streets of San Francisco . I should say it's probably not worth the cost for most people compared to going to Dreamin' events . (In fact, I should probably write a whole post about that!) But Dreamforce is something to see. I think everyone in the Salesforce ecosystem should experience the Mother of All Salesforce Events at least once. I mean, I got to see U2 at my first Dreamforce. It's not all conference rooms and PowerPoint. So if you're going to Dreamforce this year, or thinking about it for the future, here are my top tips for surviving and thriving. Comfortable Shoes 👟 I'm kidding here. Yes, you should wear comfortable shoes. You're going to spend all day on your feet. But this piece of advice has been given in a million blog posts, podcasts, and Trailblazer Community posts already. It was just a joke for me to throw it in. This post is not meant to be a rehash of what's been written before. Shorten Your Lanyard 🏷️ I've been on the record many times as a fan of name tags. And your Dreamforce badge is truly required to get into any space of the conference, so you're going to be wearing it all the time. Make your name visible by shortening the lanyard. I usually tie a small knot in the lanyard, which raises the badge closer to my chest than my stomach. If you're wearing a hoodie, you can put the lanyard around the hood, instead of just on your neck. If you have a collar, put it outside that. But I still think tying a knot is the best way to go. The benefit here is that even when you're sitting down, other people can see your name easily . Trust me—you'll appreciate it when you can remind yourself of the name you didn't quite catch over the noise. Skip the Marketing Sessions - And Too Many Are Marketing Sessions There's just no way around it, if a Salesforce employee is delivering the session, it's almost certainly going to be marketing. Lots of blah blah blah about the hot new thing and how it will change everything. (Last year and this year: Generative AI.) In my opinion, these are total wastes of time. This applies—perhaps especially applies —to the keynotes. (Yes, all the keynotes. Marc Benioff puts on a good show, but the main keynote is nothing more than an advertisement for new "features" that you probably won't ever use.) And anyway, you're going to hear about the main marketing push ad nauseum in a million other places. The main keynote doesn't have any other sessions happening at the same time, but there are plenty of other things to do with your time. As for the rest of the keynotes, I say look for sessions where you can learn real skills or meet real people instead. The other kinds of sessions I find tiresome are those where a partner presents with their customer about a big implementation. You can usually spot these with titles like "How the Food Relief Society Served Ten Million Meals" or "Quilts for Cats's Digital Transformation." The partner is there to market their company, sharing the stage with a customer that just spent tens or hundreds of thousands of dollars on a project. Salesforce gave the session a stage based on a recommendation by the sales team, with a marketing goal, not an educational one. With an implementation that big, the partner could never present all the nuances. The resulting presentation is too-simplistic and lacking in detail, leaving admins with little they can take back and use for themselves. But that isn't the goal of the session. The partner (and Salesforce) want executives at potential customers to be wowed so they'll do their own big implementation. As a hands-on-keyboard practitioner, I find these about as useful as the demos in the main keynote. Those demos are cool, but all I can think as I watch them is, "How many millions did this take to implement? And how much would it cost in annual licensing to support that org in real life?" Find the Right Sessions 🔍 So what sessions are worth adding to your agenda? Look for three categories: Anything presented by members of the community. These are going to be practical How To kinds of sessions, with real demos. (I'm biased, of course, since this covers my own session.) Community Cove events. These are also usually created/hosted by community members, though sometimes organized by Salesforce itself (members of the Trailblazer Community team). They're more informal, less "session" and more networking and discussion. Sessions run by Product Managers. This is the major exception to my rule, above, about sessions run by Salesforce employees. The product managers are actually building features, so these are chances to learn from the maker, see the roadmap for feature upgrades, and ask questions. Dreamforce has relatively few of these sessions, as they're more a focus at TDX. But read the Agenda Builder carefully and you'll find some. A special session worth mentioning here is True to the Core , which also features product managers, through it's actually facilitated/moderated by Parker Harris and senior technical leadership. This is the biggest, most public, place for admins to ask technical questions and advocate for feature improvements and interface upgrades. Network Network Network 🛜 The real reason to attend Dreamforce is to meet and hang out with people from the community. Sessions are interesting, of course, but the real value is in the people. When you're stuck on how to build something later these are the people you'll be able to ask. So introduce yourself to people in lines, sitting next to you in breakout rooms, and at meals. You never know when you'll run into someone you recognize from Ohana Slack or threads on the Trailblazer Community. Now you can pal around for a bit and turn a virtual contact into a real life friend. Pro tip for particularly for introverts: Find yourself a "Conference Buddy." The crowds are going to be overwhelming. But if you can find one person and connect with them for a bit, you'll be reenergized. Watch the online communities for events for newbies, including the Bacon Breakfast , the annual walk across the Golden Gate Bridge, and others. Definitely go to the First Timers meetup . These are great places to meet people who are also looking for a friend. Do the Quest—it’s fun! 🏅 Salesforce has significantly cut back on the massive swag load of previous years. But they still build in some kind of "quest" with good prizes like shirts, hoodies, and plushies. You usually have to attend a session or two of particular kinds, do a Trailhead module, and meet with some of the sponsors. It's not that hard. Check the Events app for the requirements and what the prizes are. There's usually also a paper handbook available at the information booths. Even if you have no interest in the prizes themselves, the quest can be fun. Plus it's something to do with people as you get to know each other. I have great memories from speed-running the TDX quest in 2023 with the Four M's (me, Monica, Misty, and Melissa). Besides the silliness of getting the prizes as quickly as possible, we had fun at the "escape room" and some of the other goofy games. Plus sometimes you might actually learn something, discover new products, features, or apps that you didn't know about, or even meet a product manager or find an exhibit booth you woud never have come across. Feed the Circular Economy ♺ Even if you don't care about the quest prizes and swag from exhibitors, you probably have someone in your life you can bring things back for. So take the good swag. Maybe you don't need yet another re-usable bag, or phone battery, or even hoodie. But your coworkers might appreciate them. (Or your family.) If you aren't into "stuff," that's fine. But you can be judicious. Only take the good stuff. Socks don't take up a lot of space. Plushies are bulky, but you'd be surprised how much people love them—even people that don't know the Salesforce characters. Stickers take no space at all. And yes, I'm aware of the environmental consequences and the waste swag can represent. But a few fewer stickers or pens taken from Dreamforce are not going to save the world. And if they'll bring joy to someone, that's got value. Your company sent you all the way to Dreamforce, you can share swag with coworkers as a sign of your appreciation. Or save the haul to bring with you to a user group or Dreamin' event. There are plenty of people that are involved in the ecosystem that don't make it to the big events or don't get their hands on a piece of swag they were hoping for. The more you give away, the more you build friendships in the ecosystem and spread the fun. Eat 🍴 For my last piece of advice, I'm turning to the practical: Don't forget to eat. Your Dreamforce registration comes with lunches. You need fuel to keep going. So make the time to eat. Bonus points if you manage to eat with one of your new friends. But even if you just need some time to sit quietly by yourself, get those healthy calories in when you can. And this applies doubly to dinners, in my experience. Lunch is at least served for everyone on the Dreamforce campus. (It might not be the perfect food you wanted, or the options might run out, but it's pretty good, relatively healthy, and will keep you going.) But dinner is on your own. You might manage to get food at one or another party, if you attend them. But I've learned not to count on that. Sometimes the food is insufficient. Or it's all gone by the time you arrive. Don't compound the exhaustion and the jet lag by also not having dinner. Grab a few people and head to a restaurant when the long day of sessions ends. Don't be shy: You can be certain that any group you announce a dinner plan to will have at least two or three people that want to eat with you! I also like to swing by Trader Joe's and grab some supplies to keep in my hotel room, both for breakfast and to keep some snacks with me during the day.
- Cooler Than Validation Rules
I've been working on an approval process for a client lately. I bet that's for a sentence you don't hear too often. But despite not having gotten updates in ages, they're a pretty cool feature. However, this post isn't actually going to be about approval processes. It's just that our story starts there. You see, I had a pretty simple requirement: Each step in the approval would move a record to the next stage. But we wanted to require certain fields be filled out at certain stages, as the record advances through the approvals. Page layout tricks wouldn't be the answer, since some approvers would only be approving, not editing the record. Time to write a validation rule . Only when I started testing, I found that records kept changing status and ignoring the validation. Thing I Learned: The workflow field updates that happen within an approval process do not fire validation rules. Fortunately, a few minutes' searching found me at this blog post , by Yumi Ibrahimzade, with a workaround. Build a before save Flow that checks if the record has certain conditions and then use a custom error component to show an error, similar to a validation rule. Problem solved! So interesting! I had never used the custom error component before. Idea! 💡 That got me thinking. This custom error on a before save Flow is pretty neat! Cooler than validation rules 😎 on a lot of levels. With branching logic and all the other powers of Flow, you could get super custom with what kind of validations you want. For example, you can make cross-object validations, that check the status of related records, not just fields on the record itself. Or you could validate based on non-record statuses, like day of the week, or user attributes, or even custom metadata records. Here's Yumi combining custom errors with Flow fault paths, so fault paths don't cause a Flow to fail silently for the user. I want to use these before save validation flows everywhere! Reality 🥱 But in truth, I'm sticking with validation rules. Sorry to be the splash of cold water. Validation rules have two major advantages: Transparency As much as the backwards formula logic of validation rules constantly trips me up (and it does!), they live right within the object manager. You can see all the validations for a particular object in one place. And you can also see what validation rules relate to a particular field right within that field's edit page. Ease of Maintenance I absolutely love Flow. But it takes more than a handful of clicks to make a new one. Or to open an existing one. Or even to activate and deactivate flows that are already built. And don't even get me started on the pile of Flow versions. So if you need a validation rule that can be built with a rule, it's going to be far faster to create a validation rule. Fewer clicks = happier admins. Let the Gears Turn ⚙️ But now that we both know about this, let it rattle around in your subconscious. Can you think of validations that would help keep your data clean that weren't suitable for validation rules?
- Design for User Success: Think About Text
You know what's also part of the design of your Salesforce pages? A whole lot of text. So far I've talked about color, eye movement, where you put fields, and more. But there is text around all those things, from field names/labels to the content of the fields themselves. Those are all part of the design! Field Labels When you create a new field, how much time do you really spend thinking about the label? If you're like me, it probably depends a lot on the context. Organizing a spreadsheet listing all the fields that will go into a new object I'm scoping out? I probably take some time to consider the labels in conjunction with each other. (And my stakeholders might have opinions as well.) But throwing together one or two fields as I'm making an automation or responding to a user request? Those field names happen more organically. Those two situations can result in very different sets of field names. This is my reminder to spare a thought for how field labels are going to interact with page design and other uses (like on a report). You get forty (40) characters in a field label. That's it—there are no workarounds. Keep this in mind, particularly when you're about to create a whole series of fields that you want to go together. If you have one that's going to be longer than the rest, best to abbreviate them all from the start than to realize the problem late in the game. If the labels in a section don't look like they go together that's going to be noticed at least subconsciously by your users and give just a little hitch of distaste. Nobody want's that! Balance Consider the screenshot below. It's not perfect—none of my designs are. But it works well enough. You've probably seen a phone/email section that looks a lot like this before. I'm quite happy with that section.. The phone fields on the left are grouped logically together. The email fields on the right parallel them. In the case of this org there is one more email field than phone field, so the right column is a little taller. But that imbalance makes immediate sense so I don't think it is a problem. Then the Career Fields of Interest section is balanced with just one field in each column. (Note that it somewhat violates a suggestion I make below. But I'm not perfectly consistent.) Then the Communication Preferences section has four checkboxes. They're all in a single column because even though it makes the overall page taller (more scrolling = bad), dividing them into two columns would make the logical grouping hard to figure out. And I expect people will collapse this section most of the time, so the height matters less. Help Text First of all, consider this my plea for including help text as frequently as possible as long as it's useful. Users really do appreciate it when it's there! This can take a moment extra each time you make a field—and particularly when you're making a bunch of fields at once—but it's worth your up-front seconds to save users a minute or more of confusion later. Let me also note the aesthetics here: If some fields have help bubbles and others don't it can make your page layout look uneven or unbalanced. We wouldn't want that! No, seriously. We don't want that. Notice the screenshot above, where two fields in Communication Preferences have help bubbles and two don't. That bothers me. I might need to to fix it right now. In a perfect world I would say that all fields in a section should either have help text or none should. But the world isn't perfect, so you'll have to weigh the small clutter or unbalance with the useability tradeoff of the guidance. Guidance Speaking of guidance, here's one of my favorite tricks: See how there are fields in this Phone Interview section that start with a 🗣️ emoji and then actually have the what the user should convey to the stakeholder? Without having to use a screen flow we've converted part of a record page into a script for a phone interview itself. How did we get these guidance sections onto the page? Simple! They're text formula fields. Not complicated formulas, either: This trick allows you to place text within the detail page layout instead of having to put it in a rich text component above or off to the side! 1 or 2 Column Sections Probably one of the things that drives me most nuts is when I see someone's page layout that has a long text field in a single column. It's just...wrong. It's one of the first things I clean up when I work with a new client. (If I can get agreement to change page layouts.) If you're going to make space for your users to fill in a longer narrative it should not be squished into a single column. It will be hard to read, wrap funny, and force users to scroll further to see things below that field. Put those fields into a one-column section—on their own if need be! If you create a one-column section and turn off display of that section's header it will act as though it's part of the section above it (even collapsing along with the collapse of that section). Look no further than the standard Description field on Account. Salesforce puts it into a two column section by default for a reason. And when you create a new long text field and have Salesforce auto-add it to a page layout, it goes into the bottom of the first one-column section, while most other fields go to the bottom left column of the topmost section. This different behavior exists for a reason! By the way, multi select picklists should get similar treatment. When there are multiple items selected, MSPs look like long text (separated by semi-colons). And in edit mode you're going to need room for both the choices and the selected choices. Look how squished an MSP looks when it's in a single column in edit mode: Isn't this better? Related List Details Here's another trick I like to use. It can be hard to glance at a related list and get all the information you might want about records there. So create a formula field on the child object that pulls together a few fields' worth of information and display that field as the prominent column in your related list. Now you probably don't even have to open the child records. Here are individual grades on a student's report card: The Detail column tells me what I need to know without having to add three columuns to the layout. Or you can put details into the name of a record using a before save flow every time the record is edited. These college applications' names tell most of the story. Design Is Not Just About Imagery and Color When you're adding text to your Salesforce pages, that's part of the design of the system, whether that text is a field label, the contents of a field, or the text within a help bubble.
- Design for User Success: Button Order
How much thought do you spend on the order of buttons in your instance? So often I'll see a vastly different button order on pages for different objects and it makes me crazy! This post is my plea for you to give some thought to those humble, but oh-so-important buttons. Those buttons constitute a huge percentage of the things your colleagues are clicking on. So save them mental effort and save them clicks! By the way, in this post I'm going to refer to "buttons." But depending on the context in Salesforce these are sometimes called "actions" or "quick actions." The name isn't important. I'm talking about the things at the top right of the page that users can click to do things (and also the things at the top of the Chatter feed and the Activity Feed that users can click to do things). At the top of the page these always look like square buttons. In Chatter and Activities they can be tab-like, or button-like. Side note: I think it's very confusing for users that those buttons stack similar items (like Task actions) under carats. So I usually set my Activities component to "Use tabbed activity view," which goes back to the tab-like buttons that were the original design. Salesforce changed the default and all existing orgs to the new style about two years ago, so this is probably a losing battle I'm fighting. But if you have only three or four buttons, as I usually do, I think the tabs are less confusing than the dropdown carats. But for my purposes today these are all "buttons" in the sense of being places on the page that, when clicked, result in some UI action. Constant and Curated Order The order of your buttons should be pretty much the same across all your objects. Of course objects that have more or special buttons are going to mess with this principle. But for a moment let's speak only of objects with the bare minimum of standard buttons such as Edit, Printable View, Clone, and Delete. [Spoiler alert: I couldn't even bring myself to write this post with them out of the order I'm going to recommend.] Edit - This is the button I assume users will click most often. (Sure, they might double-click into fields directly, but some people are focused on buttons.) If it's the one that gets the most use, I strongly believe it ought to be first, which is to say "farthest to the left" (for left-to-right languages). Printable View - I struggle even more with whether this one should stay on pages. I suspect it's very rarely used. The result can look terrible, yet it's so much better in a pinch than trying to print or screenshot the lightning page. If left on the page, I still downgrade it. In this grouping, it's second-to-last. Clone - To be honest, I often struggle with whether to leave this on the page or not. But it's super-useful at times. Among these four, if it's on the page, I figure it will get used. Delete - Clearly this is needed on the page (for those with delete permissions). But deleting data should be rare. Therefore I always put delete last in the lineup and even behind the carat to remove temptation. There are other standard buttons you may need to use more or less frequently, such as Submit for Approval, Change Owner, Change Record Type, etc, in which case you'll have to make some choices. Use these principles: Edit goes first. (Though see below when it comes to custom buttons.) Delete goes last. Others are in order of [likely] usage on the object. Keep things relatively consistent across objects. (So if you add Submit for Approval and Change Owner on two objects, maybe keep them in the same order in both cases.) Custom Buttons So far I've only mentioned standard buttons. But if you've seen a screenshot of one of my orgs you know that I use custom actions all the time , whether simple Quick Actions on an object or buttons that launch a screen flow. These start to complicate design choices. First of all, I hope you've noticed that I almost always put emoji on my buttons. [ It's just fun! 🤪 ] So they end up looking a little different than the text-only standard actions. The emojis kinda' kill consistency in that sense, but I'm not willing to give them up. (Boy do I wish I could add an emoji to Edit everywhere. Perhaps ✏️. ) Nine times out of ten custom buttons are going to be inconsistent because their labels are longer than the standard ones. (If you're making a custom button for your users, the chance of naming it something as concise as "Edit" or "Delete" is pretty low.) So custom buttons are going to be inconsistent anyway... But "Where to put them"? is the question. And I usually answer, "First." As in, "even before the Edit button." This one will vary with circumstance, but I generally figure that if we have need for a custom button, we probably want it to be more prominent than Edit. On the other hand, Edit is a small unobtrusive button, so if you want to keep it first, that's probably OK. Number Displayed The other consideration that goes with order of buttons is the question of how many will appear on the page, with the rest sitting under the carat. Don't just leave the Salesforce default here! Show four, five, even six buttons on the page if they're all going to be needed (and have short enough names to fit when screens are resized smaller). Or set the number lower if you would prefer to hide things (like Delete) under the dropdown. (But remember that some users will forget or never discover that there is anything under the carat, so be ready to train and remind.) [By the way: While you're here in the settings pane for the Highlights Panel, I suggest you always check Hide Follow/Unfollow button (desktop only). Unless you know for certain that your users follow records in Chatter, which I think is pretty rare, it's just clutter on the page.] Actions in the Feeds Let me remind you that everything I've written should apply equally to the buttons that appear in the Chatter Feed and the Activity Feed . In most cases there are far fewer buttons to consider here. But briefly: Chatter Feed - By default, Salesforce includes the Poll button. I strongly suspect nobody ever uses this. So remove it— everywhere . (By editing the Global Publisher Layout.) I think the only button you need for the Chatter feed is Post. Activity Feed - Here you are likely to have Log a Call, New Task, and Email, among others. (I usually don't use Events.) The first principle I try to use here is to move the more-used tool (email or task) leftmost. On Contact, for example, perhaps we expect to log a lot of calls. I'll put it on the left so it's the easiest to find. I also try to put the two (or more) task buttons in what I think of as chronological order. Log an Interaction (my renamed version of the standard Log a Call), used for a task that has already finished , goes to the left. New Task, an item for the future , goes on the right. Users might not pick up on this timeline ordering consciously, but I like to think it helps them make the otherwise-subtle distinction between the two buttons. How to Control Them But I guess I should briefly mention how to work with these. The first place to look is the Global Publisher Layout (Setup>User Interface>Global Actions>Publisher Layouts). This amounts to your org's global default setting for placement of actions that apply across objects. If the action layout is not overriden on an object page, what you've set here will control. So take this chance to put things in the default order you'd like. But each page layout can have its own settings if you have overriden the predefined actions. (By the way, don't be afraid to override the predefined actions! ) The order of buttons on both the page and in the feeds is controlled in the Salesforce Mobile and Lightning Experience Actions section of the page layout editor. This is where you'll change the order for a particular object and where you'll add object-specific actions, like the custom buttons we talked about above. (Of course, if you're not using classic page layouts and have switched to Dynamic Forms , then you'll control button order in the Lightning App Builder.) You Have the Power Now that you've got all the tools, go and apply you design sensibility to the order and placement of buttons and actions on your pages!
- Design for User Success: Screen Flows
Here's an idea most people don't consider: Screen flows can be page layout elements. I'm not talking about the design of the screens in the flow. (Though clearly you should design them.) I'm talking about using screen flows as part of the way you design a record page. Whether you're using just standard flow components or add-ons from UnofficialSF or other resources, you have possibilities for changing the look and feel of screen flows in ways that you might not have with any other Lightning App Builder components. For example, want to display fields in three columns? Not really an option on a Lightning page. But you can have a flow with three columns very easily! If you think about embedding a screen flow like that onto your page layout, it means that at least a portion of your page has all the design possibilities you can work with on a flow screen. Functional Screen Flows First, let's think "in-the-box." Screen flows were originally a way to take users through a guided script, with field updates, selections, and complex branching logic with automatic record updates. So they were originally conceived as standalone screens that users would work within. But in Lightning you can either have a screen flow take over the screen (like with a pop up) or embed it on the page. So consider where the flow will sit and how that impacts your overall design. Load right away? Consider that flows load slightly more slowly than most other page elements. So if you put your flow somewhere that's going to show immediately your users may see everything else load while the flow still has a progress spinner. (Not the end of the world, but something to keep in mind.) Still, if this is a flow users are going to use often, then right on the page makes sense. Of course you should also consider when users should take in the content and how they will interact with it. (Remember how eyes move around the page.) Hidden behind a tab? If this is a screen flow for users to do something they aren't doing regularly on this record page, that's a good time to put that flow behind a tab. As long as users can get to it with a click, it's going to still be easy for them. And the flow only loads when needed, which is good for performance. In a large or small section? It can be pain to test, but make sure you think about how your screen flow will appear based on the size of the section it appears in. If you're using the default page template with a small right-hand column, that's very different than the 50/50 split. Launched from an action button? If you don't want users to see the flow on the page itself, which can impact both the way the flow looks and the user experience, the out-of-the-box option is to launch the flow from a quick action added to the buttons at the top of the page. Launch Flow in Modal One of my famorite [free] components is Launch Flow in Modal from Salesforce Labs. It does exactly what it sounds like: allows you to put a button on your page that will launch your screen flow in a modal window (a "pop up"). And you can put that button on pages (like the Home page) that don't normally have actions. Screen Flows Only For Placement My final note is to remember that screen flows don't have to be for interaction at all. You could use one to just generate a block of content and then place that wherever you need. In this screenshot you can see an example: That block of text on the right column is a screen flow that has collected data from multiple related records, performed some calculations, and merged the results into a text block. Even though this is a screen flow, there is no intent for users to interact with it—it only exists for them to get the story told by the data merged into an understandable format. Effectively, this screen flow has become another way to include text on my page, one that I can design differently than fields and field labels. [Updated 7/11 with hat tip to reader Elizabeth Carena for pointing out the tip.] Note: You can't remove all buttons from a screen flow by hiding them. The editor will require that there always be at least one unhidden. But if you don't need any buttons, what you can do is uncheck Show Footer. Since the buttons show in the footer, that effectively removes them. Simple But Powerful I don't think I'm suggesting anything revolutionary here, just reminding you that screen flows can be part of your design thinking. But once you have that in mind, there are some potentially powerful additions to your design toolbox!
- Design for User Success: Eye Movement
Call them what you want, but a record page, a Lightning page, an app, or anything else you work in in Salesforce is going to be displayed to your users as a web page. (Unless they're on mobile.) So the first thing you should keep in mind when you design your Salesforce pages is that people interact with your pages the way they interact with any other website. That means that [for speakers of left-to-right languages] eyes move across the page from top left to lower right, then bounce up to the middle of the window on the right, then work their way back across to the top left. More-or-less like this: A quick note here: I'm ignoring the Salesforce header bar. Your users do too. They've scanned this in the past from left to right and taken in the logo, search bar, help and profile icons, and the names of the object tabs. In everyday use, I believe they essentially don't even see this part of the page anymore. So when a new record page loads, this is the direction of eye movement across the part of the application you actually want to design for. Ignoring the Details Pane (for a sec) The first thing your users are going to train themselves to do is to ignore the details pane on the page—you know, all those important data fields! Not that details aren't important, but unless looking for a particular field, users know they don't need to get into the weeds of the fields when the page first loads. That's part of how the eyes can skim down to the bottom of the window quickly to take in the overall architecture, the brain knows that the details section has lots of information, but the data in the fields can wait for a moment. As designers, we are going to use that tendency to our advantage. Bounded by the Edges It seems worth nothing that we can also be confident our users' eyes are going to stay bounded by the window frame. Even the OS is designed to help us concentrate on the active window, not to mention the browser app design. And the user knows they need to stay within the focus window as well. So their eyes are not going to zip out of the frame before taking in what's there. General Principles I'll go through some of the most basic conventions I use in my page designs. Feel free to steal! Details on the Left (loading first) First of all, I'm a firm believer in loading to the details pane and keeping it on the left part of the page. (And, of course, thse pages are using the 50/50 template.). As noted above, this lets my users learn to scan the whole page design in a quick glance. If you load to a related list tab, first tof all they don't all load instantly. And second, I just don't think loading to related lists is usually what people need. Since I also always load to the leftmost tab in a tab component for consistency, that means Details will be the first tab. I hate the Salesforce default of making Opportunities load to the Related tab. Fields you want to draw attention to on the right, "above the fold" Using the newspaper analogy, I consider the bottom of the screen to be like the fold of a newspaper. Just as readers are more likely to read the first few articles at the top of a newspaper section, anything you can see before scrolling is going to get more attention. To that end, I love to use the Related Record Hack (not called that in the blog post) to put rollup summary fields or other important pieces of data in a prominent place toward the top of the right-hand column. By putting such rollup summary fields or other information over there, it's in the place that we know eyes are going to linger for a moment and, therefore, be more likely to get the attention we want. Banners Top Right (or Full Width) Notice another thing in the image above: There's a Lightning Messaging Utility banner in the top of the right-hand column. Again, it's where the eyes might linger. And it looks different enough from the rest of the page to catch the eye. Here's another example of a banner, this one across the whole page because it's meant to complement the Path component. Important Related Lists Upper Right You may have noticed in all these screenshots that I put the Related List Quick Links at the top of the right column. I think that's a super-functional component and a good place to make it easy to find the list you might want and work with it. I pretty much always put it in that position. (And check the box to hide the header! There's not much value to showing "Related List Quick Links." People know that's what they are.) But then I also put the most imoprtant one or two (or at-most three) single related lists in the right column. Those are the ones I think users are going to need to interact with most frequently, so I can save them clicks and time. Other Tabs Last, but not least, the eye comes to the tabs in the left column. I mentioned that the first-loading tab will be details. But you can have a whole bunch of other tabs here as well. As I said at the beginning of this series, consider taking fields off the details page layout and putting them behind tabs so they're easy to find with just a click. Make thematic tabs that have fields and related lists for a single purpose. We've got those eyeballs exactly where we want 'em. 🧐 Once we've thought about where focus is going it can help us start organizing our pages to guide our users to find the right information and work effectively. And isn't that what we're all trying to do for our colleagues?
- 🌈 Design For User Success: Add Interest through Color
When you're designing Salesforce record pages, you're not just placing fields for a database. This is the main application your colleagues spend their day interacting with, the place where they do their job. [At least, I hope that's the case! If not, you might want to spend some time searching out those shadow systems where people are keeping that critical data you need for reporting!] So if your colleagues are going to spend a good portion of their day in the system you're responsible for, perhaps you can give them some joy. Why be boring? Whoever designed your office (back when people had those) didn't just leave bare walls and a sea of cubicles. Usually. I think the same goes for our Salesforce orgs. Classic page layouts were functional, even if they looked oh-so-2003. But people expect more from computer systems in 2024. I bet you've had that moment when someone shares a screen or logs you into a system with a tiny font and icons straight out of Windows 95. It doesn't inspire confidence, does it? I'm advocating for making our Salesforce orgs look as well designed as the consumer websites we all access every day. (At least to the best of our abilities and within the constraints of Salesforce itself.) We may not have carte blanche to design however we want. But we have a lot of free and easy options most people don't take advantage of. I'm going to admit that this recommendation, comes with a bit of controversy, or at least a little need for nuance. Color may not work well for visually impaired users. Color choice is important. Web Content Accesibility Guidelines (WCAG) have opinions on color, particularly around contrast. I strongly encourage you to think about accesibility whenever you're designing. So please consider my recommendation to use color to implicitely mean "add color appropriately and with compassion." But the point still stands: Adding color to your page brings visual interest that will aid in understanding and speed for your users. A big green banner on a page layout lets most users know even before they read a single word that a record is "good," or "finished," or "complete." Trailhead makes this point very clear, "Visual aids increase retention from 10 to 65%." Here's a tiny screenshot of a record. I bet you have some idea of its status! There are a lot of ways to play with color in your org: Lightning Messaging Utility The banner in the screenshot above was created with Lightning Messaging Utility, a free app from Salesforce labs, which I've written about before. In a Formula Field There's a method from the stone ages for displaying an image saved in the Files library in a formula field. It works, I suppose. But as I've said when presenting, this requires you to be your own graphic designer creating those images. I can admit that mine were pretty ugly. Plus those images aren't screen-reader compatible by default. But you know what are good looking images complete with alt-text that are available on just about every device? That's right, let's hear it for emoji 🥳! Salesforce Indicators There's a really cool project from the Open Source Commons called Salesforce Indicators. Indicators is a free and open surce, easy to declaratively manage, Lightning Web component meant for adding visual...indicators to your record pages. Try it out! Sometimes Color Comes Free If you add a related list to your page layout, you automatically get the icon for that object. As a sysadmin you probably barely notice this anymore. But now that I'm pointing it out, consider how that pop of color draws the eye and [might] convey some information with the icon. Of course if you add a Related Record component with a Quick Action (my friend the Related Record Hack that I wrote about last post) you also get the object icon for that related record. Themes and Branding Don't forget that you can change up the whole look for your Salesforce by setting the background color and the logo. That kind of attention to detail will be particularly appreciated by your organization's brand managers. And it gives your Salesforce pages a pop that's different from standard Salesforce screeshots. The options here are nearly endless if you want to play around in ⚙️ Setup>User Interface>Themes and Branding. Screen Flows Last, but definitely not least, screen flows offer all kinds of ways to change up the look of a Salesforce page (or section). Whether with the standard components or some of the cool things put out by UnofficialSF, you can add color and visual interest to delight and entertain. Here I just used emoji to make a pretty basic screenflow more fun.
- Design for User Success: Field Placement
Recently I've been presenting at user groups and conferences on the theme of page design. How can you design your Salesforce to make your colleagues more efficient, accurate, and happy in their work? Too often we, as admins, don't take time to think about design and the user experience. These aren't new ideas. It's a while already since I wrote about the 50/50 split. (If you don't remember that post, I'll forgive you. I can sum it up: Don't use Salesforce's default Lightning Record Page template! Changing your template to give two equal columns lets your users take in more information more quickly when they look at records.) I'm going to assume that you're already working with a page template that can show your users the information they need. But let's go a step further than just the overall page frame. Let's ask, "Where am I putting fields?" Page Layout Editors Things don't get much more fundamental in Salesforce than page layouts! You've got two fundamental editors for your page layouts: The "enhanced" [before I even got into the ecosystem] page layout editor. Basic and functional. New-and-shiny Dynamic Forms right in the Lightning App Builder. Let's start by thinking about where you put fields, not how you get them there. Go ahead and use whichever tool you prefer. Both have their pros and cons. The considerations for placement don't change. If There's a Need, It Leads Most of your required fields should be toward the top of the page layout. You probably already knew this, but it's worth specifying. And I bet now that you're thinking about it you can come up with some places where you could do better. Ever have that problem where you're trying to throw together a quick test record and you can't do it without scrolling all over the page to fill in a bunch of required fields that aren't grouped? So frustrating, right? Perhaps that means the page layout needs some love. If there are fields without which a record would be entirely meaningless—or even impossible (such as those required at the database level)—then your users are probably planning to fill them from the moment they click New. Help them with this. Put required fields right at the top of the page, in the first section a user encounters. Even if a field isn't actually required on the page layout, the sooner a user comes to it on the New Record screen, the more likely they are to fill it out. Make that first section count! Of course the most obvious example here are Name fields. Just as the First Name and Last name fields are the first and second fields you expect to enter when creating a new contact or lead, every other Salesforce record has a name field of some kind. If it's one your users will fill, put it in the top left spot—the first field they encounter. Auto-numbered records don't accept user input for the name, so they aren't a factor for data entry. But I still prefer to put an auto-numbered Name field pretty close to the top. That way when we need to refer to it we know where to look: in the same place we would look for any other record. If we're talking about a record that has a Stage (or Status), such as Lead, Case, Opportunity, or so many custom objects we've all built, I'm going to argue these probably go pretty near the top as well. And that brings me to the next principle. Like Things In Like Places Those Stages (or Statuses) are important, so they're going near the top of the page. And generally I want to put them in a similar location for all objects. That way, even without thinking about it, on any record my users know where to glance to find the current stage. On my pages these fields are usually at the top right of the first section on the page. My users get subconsciously trained that whenever there is a Stage, it's a picklist they adjust at the top right, probably next to Name. Actually, I think I got trained by Salesforce. The default location for Stage on an Opportunity page (in Classic) is toward the top right. That's probably how I got into the right-column habit in the first place. Of course, there are all sorts of other ways users are going to interact with Stage, such as with a Path component, through Lightning Messaging Utility banners, through a Quick Action, or perhaps the stage changes through automation. But whatever underlying field is represented by a Path or banner I also put directly on my page layout. That ensures ease of editing in the full Edit modal, makes it available to adaptive tools like screen readers, shows it in obscure places like the printable view, and even makes it available for editing in list views. Got an object with a Start Date and End Date (like Campaigns)? Make sure you keep them together! There's nothing more frustrating than entering the start date and tabbing into the next field only to find that it's not the end date. I tend to put record Owner on the right and toward the top for any objects where it's actually used. There are other reasonable placements, for sure. Just be consistent. [If Owner isn't important for your organization there a few objects you won't be able to remove it from. In that case, bury the field somewhere it won't be obvious, probably down with the rest of the system fields, so you at least reduce the visual clutter.] Speaking of which, you have to decide how you feel about the system fields. There's a valid argument for taking Created By, Created Date, and Last Modified Date off the page to just reduce overall clutter. On the other hand, particularly for sysadmins, these can be very helpful fields. I leave these on all page layouts, even for simple objects with just a handful of other fields. I also keep the default System Information section, I turn on the header display at all times, and I leave the section at the bottom. I usually even add one more blank space between the last substantive field and the header of this section. For those users that know, they can collapse the section and it will stay that way for them in the future. And even those that don't collapse it have that extra space to clue them in that they can stop reading before that last section. Consider Removing Fields I mean it. There are fields you don't actually need to be on your main page layout. "Main layout" meaning the "Details" component of most Lightning Record Pages. There are all kinds of fields you can move off the details section and put behind a tab or somewhere else on the layout. NPSP has dozens of donor rollup fields, for example. Most users aren't looking these when they go to a contact page. And if they are looking for the rollups, it's easier to find them with one click behind a tab than to scroll down looking for the right section. Fields that users don't edit, like rollups, are great candidates for putting behind a tab. You never need them to show up when the user clicks Edit and gets the fullscreen editing modal. With Lightning there are all kinds of other field moving possibilities. If you have a handful of fields that are only edited occasionally, and only together, not in the context of other record updates, you can put those fields together behind a tab. Teach your users that's where the fields are and that they can edit them using the pencil icon. Bam! Now you've made users more efficient (fewer fields to wade through when editing) and happier (able to see just the fields they want when they want them). You're a hero, just by taking some fields off the page layout and putting them somewhere else. The How of Moving Fields Around Now that you're thinking about why, when, and where to move fields, let's take a moment for the How. There are two ways you can do this: The Related Record Hack My preferred field moving method is known as The Related Record Hack. Despite what I call it, this is a Salesforce-built and -approved feature. As described in this post I wrote on that other blog several years ago, you create a Quick Action and place it on the page using the Related Record component. "Hack" in the nickname refers to the fact that you accomplish it using a Quick Action and a Related Record component, though it's neither to take any action nor to display a related record (just the record itself). Dynamic Forms Clearly Salesforce is moving in the direction of Dynamic Forms. Using Dynamic Forms you can place single fields, build field sections, and conditionally hide or display as you desire. Full disclosure: I'm not using Dynamic Forms yet. There are a handful of limitations and frustrations about the feature that have kept me away. Each release is making this feature better, for sure. In truth, the main thing holding me back is that I switch between orgs so often. It would be a pain having to constantly juggle between the two methods. That was Just Step One Who knew I would have so much to say just on the topic of moving fields around on your page? But this is just the beginning! There are all sorts of things you can do to make your Lightning Record Pages more fun and interesting, including adding color, directing your viewers as they scan your page, and more. Watch this space.
- Band-Aid for New Cloud Reporting
Previously, I explained how hard it is to do some simple kinds of reporting in the new Nonprofit Cloud and Education Cloud. In particular, I was looking at the impossibility of making a report that would show people (Person Accounts) and their donations (Gift Transactions) while also being able to show or filter based on donation rollups, like Total Giving (over their lifetime), Gifts This Year, etc. The problem stems from the fact that giving rollups, in the new clouds, do not reside on the account record, nor even on the contact record. They're on an extension object called Donor Gift Summary. I wasn't going to leave my client without the reports she requested, particularly since I think her requests are entirely reasonable. So I found a workaround. But I don't love it. I’m a little afraid it could introduce problems in large data volume environments. Still, it works and I'm proud of having thought of it. So I'm sharing it with you. But caveat emptor and YMMV (your mileage may vary). A Lookdown Relationship Step 1 is to create yourself a new custom field on account. I called mine DonorGiftSummary. This is a lookup field, to…wait for it…Donor Gift Summary. This is a lookup field. But it’s really a "lookdown" because Donor Gift Summary is already a child object to Account. (It has a lookup field of its own, called DonorId, that looks up to Account.) Yes, I'm intentionally creating a redundant field here. Dolores Does the Work Next I built a DLRS rollup to fill the DonorGiftSummary field. Parent: Account Child: DonorGiftSummary Field to Aggregate: Id Aggregate Operation: First (or last, since there is only ever one DGS) Mode: Process Builder In plain English, what that rollup does is take the Id of the Donor Gift Summary that goes with each account and put it into the DonorGiftSummary field. Because it's set to the mode "Process Builder," this rollup will only fire when called by other automation. I then used DLRS's Schedule Full Calculate button to set this rollup to run once per night around 4am. (If you want to hate on DLRS, you’re welcome to fill the field using a scheduled flow instead. But it took me less than three minutes to build, test, and schedule that DLRS rollup.) Schedule Your Work As noted above, we run this rollup nightly, an hour or two after the Data Processing Engine (DPE) for donor rollups runs. If this is the first time you’re hearing the phrase "data processing engine" or seeing the acronym "DPE," consider yourself lucky. I'll have to write about those sometime soon. The Short Version: a DPE definition is like a Flow that can collect, filter, and calculate, but it does the bulk of the work off-platform. Once you go through the new cloud setup steps, you'll have created a scheduled flow that runs the donation rollups DPE definition that Salesforce provided. This definition takes all your donation data, calculates the rollups for accounts, and then inserts donor gift summary records. Unfortunately, the DPE definition that Salesforce has provided so far has all kinds of problems, including getting some rollups wrong. (Oops.) And DPEs aren't Flows, particularly in the sense that nobody understands how to build or modify them. But what matters for the timing of this DLRS is that the DPE deletes all donor gift summaries and then inserts new ones, rather than doing an upsert (updating those that exist and inserting the new ones that are needed). So we have to make sure the DLRS runs daily and after the DPE is finished or else our new field will be blanked out for all records each night. (I assume that setting this DLRS to realtime mode would be a disaster when the DPE goes to insert all those donor gift summaries at one time.) The "Lookup Lookdown" is the Magic Now that we have a lookup field on Account that points us to a single DPS record, we have the option of adding any of the DGS fields to custom report types via lookup! (Great that we can do this. But it's still a pain in the butt to have to edit all of our custom report types.) We also now have the option of formula fields on Account that would span the lookup relationship. Those could allow us to put rollup fields on the page layout without using the R2D2 component [Not my favorite component.] or to calculate other things about an account's rolled-up/summarized donation information. Bam! Now a report that was simply impossible is unlocked. 🏆
- Extension Objects: There’s Nothing to Like
Continuing our exploration of the new Nonprofit Cloud and the new Education Cloud, let's look at the Achilles heel of Industries solutions: the extension object. I noted in The Emperor’s New Clouds that extension objects are a workaround for the fact that the new clouds are built "on core." More specifically, extension objects are how building "on core" deals with adding fields that really ought to be added to standard (or "hero") objects like Account and Contact without having a managed package. I don't understand why Salesforce.org is so dead set against having a managed package for the new clouds. As we're going to see, not having fields where they belong is a critical flaw that makes the new clouds difficult (I would say nearly impossible) to use and increases the costs of implementation and upkeep exponentially. Even Financial Services Cloud has a managed package, so it's not like building on "the Industries model" requires that everything you put out be "on core." Recap on Extension Objects, or "Sidecar Objects" A quick reminder. Salesforce.org has chosen to build the new clouds "on core" and not have a managed package. That means that functionality relates to objects you can only see with special licensing that opens up access to Industries’ “standard” objects, some of which are new for the nonprofit clouds and others come from prior clouds like Financial Services, Health Cloud, and Public Sector. Any new fields referenced in new cloud functionality are on Industries objects because fields can’t be added to the “hero” objects that have been around forever. New fields can’t be placed on hero objects unless you publish a managed package, nor can picklist values be added to existing picklists. In those places where the engineers would have added a field on a hero object in the past in a managed package (say, in NPSP), they instead create an extension object. In my prior post, I used the analogy of an apartment and parking garage to explain these additional objects. I've also heard them called "sidecar objects," an analogy to adding additional passenger seating to a motorcycle or bike. I like that analogy because it makes it easy to start to point out the absurdity of extension objects. A sidecar is a nice addition to a motorcycle, it allows the passenger better visibility and allows the driver to see them during the ride, unlike riding behind the driver. In a pinch, I suppose, a sidecar would allow three passengers on a motorcycle. Plus they're useful for those that want to bring a dog along. (I don’t think dogs would be that good at riding pillion, which is one inoffensive term for riding tandem. I probably just taught you a new word. You’re welcome!) Of course, sidecars often take flak for being uncool. And they're murder on fuel efficiency. (This analogy is getting more and more apt!) Plus you very rarely see motorcycles with more than one sidecar. If you need multiple passengers that's what cars are for. Bloatware The other thing about extension objects is that they add massive bloat to the entity relationship diagram (ERD), the visual depiction of the tables in your database and their relationships to each other. That's no small problem! I don't particularly care that the diagram is a mess—though it is. But a data model that complicated is makes it harder to understand and internalize, harder to support, and nearly impossible to analyze using Salesforce's reports and dashboards. I headed this section "bloatware" because, indeed, there is object bloat going on within the new clouds. Now, I'm not opposed to complexity where needed. If you want to enable new features, you're going to have some complexity under the hood. But we want to do everything possible to hide the complexity for users. That makes it easier to adopt and stick with using Salesforce. So it’s a balance between complexity and functionality. I think it's clear that the fundraising model of the new clouds has failed in this respect. And it's happening in other areas as well, with the main culprit being the extension objects. Earlier, I wrote about Donor Gift Summary and Party Relationship Group. Now let me tell you about one more: Contact Profile. This one's so bad that I keep blocking it from my conscious mind. The Dumping Ground You know how sometimes people have more than one email address? Like a work email and a personal email. You’ve encountered this, I would imagine. Since Salesforce was originally a sales tool, there's only ever been a single standard Email field, which presumably was the work email of people at the accounts you were selling to. NPSP and EDA both added personal, work, and alternate email addresses, plus a Preferred Email field, and automation to move the preferred email address into the standard Email field. Sometimes even three isn't sufficient, so people make custom email fields to add to the mix. But building "on core" means Salesforce can't put extra fields on Contact (or on Person Account), so they can't have parity with NPSP in that sense. At the same time, sometimes it's important for organizations to know demographic information about their constituents. Beyond Gender, which is a standard field on Contact, sometimes they need to capture race/ethnicity, language spoken, veteran status, and more. These are fields that describe the person, so according to normal database design, they would belong on the Contact object. But no. The new clouds introduce Contact Profile, the sidecar object for storing demographic fields that clearly belong on the contact. Solves the problem, right? Wrong. Say a new client has just walked in the door. You're doing an intake with that person and you want to enter her name, birthdate, contact information, and demographics. Thanks to extension objects, within the standard Salesforce user interface, you’ll have to do this in two steps. Name, gender, address, and birthdate can all go on the Person Account. What to do with email addresses is ambiguous because there is one email field, but she just gave you three valid email options. Assuming multiple phone numbers (home, work, mobile, alternate) and multiple email addresses, those have to go on Contact Profile. Plus all the demographics have to go there as well. So you would have to create and save the Person Account, then click New in the Contact Profile related list, then enter the other pieces of data. How are we going to make that understandable for a new user? And even if they understand what data goes where, they're going to rightly hate all the extra clicks. Someone [that shall remain nameless] at Salesforce made the argument to me that it won't be common to want to create a contact and at the same time fill in their demographic details, so this complication doesn’t matter. I respectfully and very strongly disagree. Sure, in theory we could replace the new person account screen with a screen flow. Good luck ensuring users never find a "new contact" link in some obscure part of the platform user experience. And Yes, webforms like FormAssembly can make sure the data gets to the different objects for applications and the like. But the connector mapping is not so simple anymore, particularly because contact profiles are 1:1 with a contact. And these fixes make everything massively more complicated. “No filters for you!” But even if we get past the point of entering the new people into the system, we're not going to be able to do the things we need to do after that point. First of all, we can't use List Views as we would like. I'm a huge fan of list views. They're an easy way to give users some bulk update access without introducing an additional tool or having to build complicated automation. List views' power comes from filtering to find the records you need and then working with them in bulk. But you can't filter based on fields that aren't on the object whose tab you’re on! Say you wanted to quickly filter a list view for all your constituents that are veterans over 65 years old. Perhaps you're going to use the handy Add to Campaign button to put them in a campaign and then send them a list email. Or you just did a survey and then added a field for which branch of the military they served in and you want a user to use the list view for convenient bulk data entry. In the new cloud data model you can't do either of these things. On the Contacts tab you won’t be able to filter for veterans because that's data on contact profile. Nor could you add their military branch if you'd added that field on Contact Profile alongside the other demographic fields. But on the Contact Profile tab you don’t have the Add to Campaign button. You also don’t have access to the Birthdate field (it’s on Contact), so you couldn't filter for the over 65s. This particular very simple example you could theoretically solve on a report. First you’d have to build a custom report type that included Contact and Donor Profile, since the new clouds don’t come with any report types preinstalled for the new objects. But inline editing on reports is much less convenient than on list views, so updating the branches of service would be misery. Plus don't even get me started on the fact that these are contact profiles and would have to be a report type of Contacts with Contact Profiles. In the new clouds we’re using Person Accounts. Users should basically never even hear the word "contact" and should never interact directly with the contact object. So we're gonna confuse them with stuff like this. But next we're going to find that reporting is actually a huge problem. Reports Are Impossible Here is a very simple example based on a real client request: "I would like to make a report of all donations that came in last week from donors that have given more than $1,000 in their lifetime so that the executive director can send a personal thank you for the gift. I need columns for donor name, salutation, address, etc, as well as their total lifetime giving, gifts this year, gifts last year, and information about the gift that came last week." In Salesforce language, in the data model of the new clouds, the request is: Report Type: a custom report type (along the lines of Accounts with Gift Transactions) Filter: Transaction Completion Date = LAST WEEK Filter: Total Gifts Amount >= $1,000 Uh oh! Total Gifts Amount (the rollup that represents total lifetime giving for a donor) is neither on Account nor on Gift Transaction. It's on Donor Gift Summary, an extension object. Not a field available in this report type! And columns for Gifts This Year, and Gifts Last Year also aren't available either. Try as you might, there is no way to modify the custom report type Accounts with Gift Transactions to show fields on Donor Gift Summary. First of all, you can't add Donor Gift Summary as one of the objects in that report type. It's simply not choosable. And if you make a report type of Accounts with Donor Gift Summaries, you can't add Gift Transactions. If you're familiar with building custom report types, you might think about adding fields by lookup. Nope. Donor Gift Summary is child to Account—how would Salesforce know which of the child DGS records to pull from? There is no way to patiently explain to the custom report type builder, "there will only ever be a single DGS for any account, so use that one." For the same reason, you can't add formula fields on Account to pull this information up either. (Theoretically you could create rollup summary fields, but you’d run out of those pretty quickly.) We simply can't make this report. ⛔️ Now let's consider whether this is an unreasonable or unforeseeable reporting need? 🤔 No. In fact, I think something like it is very common, if not ubiquitous, in fundraising organizations. Putting fields on extension objects instead of where they really belong has just broken the most basic Salesforce analytics. 🤦🏻♂️ This gifts and rollups problem is just one example. Impossibilities in reporting turn up in multiple places in NPC/EdCloud. It's a critical issue. [I actually have come up with a method to be able to solve reporting like this. But it’s not a trivial fix on many levels. I’ll write about how to do this in my next post. But the idea that every fundraising org would have to build something like what I' going to write about is more than a little ridiculous. Just because I figured out how to solve it, doesn’t mean the problem isn't very very bad.] Late Edition: Merging Broken Too Do you sometimes find duplicate contacts in your org? (Or, for the new clouds, duplicate person accounts?) I bet you do. It's already enough of a pain to find them, merge them, and then prevent new ones from appearing. What if I told you that you won't be able to merge duplicates? It turns out that if there are 1:1 extension objects on both of the records you're trying to merge, the merge will fail! Imagine duplicate donors, probably caused when someone donated with their personal email the first time and their work a few months later. Both will have donor gift summaries (DGSs) storing the rollups about their donations. When you try to merge, the system is going to reparent both DGS records to the remaining parent account. But the DGS field that looks up to the account is DonorId and it's set to be unique. In the reparenting process they are both getting the same DonorId, which isn't allowed. So the merge fails. This failure will occur for any 1:1 extension objects, as far as I can tell. But let's assume the only thing both duplicates have are donor gift summaries. In that case you'll get an ugly error: As an experienced admin with access to the back end and a good deal of hard-earned obscure knowledge, I can figure out that a record Id starting with "6SX" is a Donor Gift Summary. Then I can delete one of the records and let the merge go through. Since rollups are generally recalculated over night, the remaining DGS will be inaccurate for up to 24 hours, but at least it will fix itself. Of course regular users aren't going to know what to do in this situation. And that was a relatively easy fix, because DGSs get recalculated each night. There are other extension objects that don't get calculated, let alone recalculated. (Such as Contact Profile.) For those, someone is going to have to manually compare the values to determine which to keep, transfer them to the record that will remain, delete the records that are no longer needed, and then do the merge. A Solution Only an Engineer Could Love Extension objects instead of putting fields on the object they describe just don't make sense. Nobody would ever build this way when customizing Salesforce. In fact, I think my example of the reporting problems makes it pretty clear that this would, in fact, be a wrong architecture choice. But with the decision already made that there will be no managed package, I trust that the software engineers at Salesforce have done the best they could. It just doesn’t actually fix anything.
- Nonprofit Salesforce – the True Cost of Ownership
OK, repeat after me: Salesforce is free like a puppy, not free like a beer. You get it, right? I mean, I named the blog after this concept, so clearly I think it’s important. Let’s look at what your nonprofit should actually budget to support your adoption and continued use of Salesforce. Now would be a good time to start up a spreadsheet to estimate your particular organization’s needs. 1. User Licenses The first thing to consider is probably the easiest to calculate: You’re going to need a license for every person that’s going to use the system. In most cases, that’s the number of employees at your organization or on the team(s) that are adopting the system. I very strongly recommend that you also use a separate license for each integration that you might connect to your system. Want new subscribers from Mailchimp to come into Salesforce as Contacts? Then give Mailchimp its own login. If you’re linking a fundraising platform like GiveLively or Classy to Salesforce, give that system its own dedicated user. That way you can distinguish between the integration doing things to your data and a particular user doing things. You’ll thank yourself later when strange data cleanliness issues are popping up. [Update 3/14/2023: Every org now gets 5 free integration users, with additional at just $30/year!] And don’t forget that if you get help from an outside consultant (like me), you’re going to need a license for that person as well. As a charitable organization (a 501c3 in the US tax code, or your country’s equivalent) you’re going to get ten licenses for free. The 11th license (and beyond) costs $432/user/year. [Update 11/8/2023: The price has gone up to $495.] So even if you have a good number of people that need to log into Salesforce, it’s a modest cost. 💰TL;DR in licenses: 10 full licenses for free 5 API-only licenses (integration users) for free (# of employees/contractors) – 10 = # of paid licenses # of paid licenses x $432 = cost per year 2. Implementation: Staff Expertise and Consulting This is the section where, unfortunately, I'm not going to be able to give you any hard numbers because it’s going to depend entirely on what you’re trying to do. First, I want to point out that implementing and then supporting Salesforce requires a commitment of money, time, and focus. You’re going to want to have someone on your staff that will be in charge of Salesforce, who spends at least a little bit of time thinking about the system as a system. Even if that mainly means that they liaise with someone outside contracted for support, it’s going to require some of their time and attention. Implementation in the first place is usually something to contract with a consultant for. Do you have to? No. There are fantastic resources available on Trailhead and help available when you have questions on the Trailblazer Community. I truly think it’s viable to self-implement if you have someone interested and competent who can spend some time on it. (But let’s not forget: that person’s time is a resource you’re devoting.) If you decide to use a consultant for your implementation, I still can’t give a solid number for what that is going to cost–it’s still 100% dependent on what you need. A simple implementation of the Nonprofit Success Pack for fundraising only and some light customization of picklist values, donation stages, etc, plus a little staff training can probably be had for under $8,000 and accomplished in under three months. Maybe. If you can find a consultant with relatively low rates that’s willing to take on a small project. A custom program management implementation is going to start around $15,000 and go up from there depending on the complexity of your program. And both of those numbers are assuming just implementation. Other than making sure you’re up and running with the new system, I’m not assuming there was any ongoing support within those numbers above. To bring it down to brass tacks, most consultants charge by the hour. Even those that try to do project-based billing are often working out what they think is the price based on some notion of how many hours they think a project will take and their hourly rates for the people involved. So what’s an hourly rate within the Salesforce ecosystem? I know this is going to surprise you to hear, but it depends. Below $100/hour is pretty rare at this point. There are probably plenty of people out there with not much experience willing to take a low rate. And there are people that do a little bit of consulting as a side-hustle and, therefore, are also willing to charge less. But experienced people charging under $100/hour for work with a US-based nonprofit are a rare breed. Consulting firms charge over $220-$250+/hour, last time I got any solid information. Some people give a discount for nonprofits compared to their full rates, but that may be what brings them down to the low $200s. Some independents are cheaper than consulting firms, but not all. There can be other factors that go into a final proposal price too, such as whether this will be the start of a long term relationship, or if a project fills a gap in work for a consultant. And also keep in mind that most consultants don’t straight up tell you their hourly rate. (Though it may not be very hard to figure it out when they give you a proposal.) At any price your mileage may vary. I think you should assume you’ll have to pay around $200/hour. If you’re based in an expensive city or think you want to work with a larger firm, I recommend you assume more like $250/hr. (Better to start high and be pleasantly surprised!) But in all but the simplest cases, I can’t even begin to give you a number of hours to assume. It’s a personal and business risk to do so, but I think price and salary transparency are good for society, so I’m going to put my own rates right here in black and white: In 2022 Kolodner.com’s full rate is $200/hour. I give a 20% discount to nonprofits ($160/hour). 💰TL;DR in consulting: It’s possible to self-implement if you have someone in place with the aptitude and able to put in the time. A simple NPSP “quick start” is probably $8,000. For more custom work, assume $200-$250/hour. Number of hours is entirely dependent on the kind of implementation. 3. Must-have Apps This can be confusing for organizations considering Salesforce, but the platform was designed from the beginning to support an ecosystem of related apps. As a result, there are some things you might expect “Salesforce out-of-the-box” to be able to do that you actually need to install an additional app to accomplish. The most important example here is mail merging. If you want to generate beautiful printed acknowledgement letters for each of your donors, you’re going to need to install a merge solution. You might think that’s annoying. Or you might come to appreciate the wide range of partners that have built solutions to extend Salesforce because they’re able to easily offer their products to you through the AppExchange. Not my place to judge. I’m just here to tell you what you should plan for. A Fundraising Platform I’ve got good news for you here: the price could be free! Of course you may choose to pay more for platforms with more or different features. I’m a big fan of GiveLively, which has no up-front costs, charges just the credit card processing fee, can let your donors cover fees, and has a free integration to Salesforce that’s easy to set up and works quite well. Salesforce.org released Elevate relatively recently which also only charges a fee based on transactions and, obviously, integrates with the Nonprofit Success Pack. Full-featured systems like Classy have a contract cost on top of credit card processing fees but offer more powerful features for peer-to-peer fundraising and the like. I know these contracts can be north of $10,000/year. And of course there are plenty of entrants between those two ends. It’s not my purpose here to tell you which fundraising platform to choose, just to remind you that you should consider whether you will have to pay for the platform, pay to integrate it to Salesforce (either a fee to the platform or the time for someone to set up the integration), or devote time to otherwise bringing the information into Salesorce. I suppose you should factor in $0-$10,000+ depending on the platform you’re going to choose. Apsona for Salesforce Describing all the things Apsona for Salesforce can do is way beyond the scope of this blog post. Suffice it to say that Apsona is a tool for easy import/export and manipulation of data within Salesforce. I consider Apsona such a useful tool that I actually require my clients to install it as part of a contract with Kolodner.com. I pretty much guarantee that having Apsona available will save enough consultant time to more than cover the cost of the app. Even if you’re not paying a consultant, the staff time you save with Apsona is going to be a bargain. Nonprofits pay just $435/year for three users. The smallest nonprofits (annual gross revenue not exceeding US $250,000) can actually get their Apsona license donated. Mail Merge Solution As noted above, if you are going to want to create documents based on your Salesforce data, this is something you’ll need an app for. (Note: Sending templated emails directly out of Salesforce is free. I’m only talking here about the need to generate Word docs or PDFs.) There are three main options in this space: Apsona Email and Document Merge, Nintex’s Drawloop, and Conga Composer. Nintex and Conga are generally more expensive than Apsona, not to mention having less-transparent pricing, so it’s hard for me to give a firm number here. Apsona would cost $300 for three users (on top of the base Apsona package that I just told you, above, I consider essential.) Drawloop and Conga cost more, particularly for volume document generation, but both have fans, so I’m not saying that cost should be the only factor in your consideration. Factor in at least $300-$500/year for mail merge, if you need it, plus some time for setup, training, and updating templates. Webform Integration Many organizations need a webform integration for collecting surveys and automatically putting that data into Salesforce. Sure, you could use Google Forms for free. But there’s no integration to Salesforce from a Google Form. (And Google Forms are ugly, IMHO.) There are quite a few webform providers that have integrations to Salesforce. Again, this post is not about comparing their relative merits. The point of mentioning this here is to remind you to budget for a form tool integration if you’re going to use one. I tend to recommend FormAssembly to my clients. At the Professional level, with nonprofit discount it’s about $700/year. Most of my clients get Premier ($1,600/year) to take advantage of the Salesforce Prefill Connector and do some really cool things with forms. If you think you’ll want a webform integration, start by budgeting about $1,000-$2,000 for the tool. And don’t forget to consider some consultant and/or staff time for learning the tool, building out forms (and their Salesforce connection), and ongoing upkeep! Some forms are relatively static (like a newsletter signup), but some are constantly changing (like an application form.) 💰TL;DR in apps: Fundraising Platform – $0 to $10,000 per year, plus credit card processing fees. Apsona for Salesforce – $375/year for three users, free to the smallest orgs. Mail Merge – $300-$500/year. Webforms – $1,000-$2,000/year plus setup and maintenance time. 4. Backup Solution I’ve got good news and bad news in this section. The good news is that Salesforce is extremely robust. You’re very unlikely to lose data because of a problem at the server or data center level. Plus there is a free weekly export service that you can enable to download a backup of all your data to store somewhere within your control. The bad news is that if you actually needed to restore your data from that weekly backup it could be an incredibly painful process. Plus the backups are only weekly and require someone to actually download and archive them each week. The other bad news is that the main cause of data loss (or corruption) is people. Backups don’t only protect you from data loss due to server malfunction, they also protect against people doing stuff. And it’s the rare nonprofit that doesn’t have people. Whether somebody accidentally changes data in small chunks or bulk updates, things can happen. Backup and restore systems are one way to recover from those things. There are a couple of options in the backup and restore space for Salesforce and none of them are cheap. To be fair, I think most organizations just live with the weekly export service and hope for the best. Sigh. Just because everyone’s doing it, that doesn’t make it a good idea. The two main services that I’ve priced for clients are Spanning and OwnBackup. Neither of them has transparent pricing. But for a nonprofit, I recall quotes starting at about $6,000/year from OwnBackup. Spanning is more reasonable: it seems to be around $40/user/year. Gearset also offers a backup solution which I haven’t had a chance to try. It’s an add-on to their Continuous Integration platform, so technically you’re paying for more than just backup and restore, but it might still be competitive pricewise. [UPDATED 3/8/2022 with more up-to-date Spanning pricing.] So, yeah. A backup and restore service that you hope you’ll never use might be your largest expense after the initial implementation. And it’s still a good idea. 💰TL;DR in backup: The free option really isn’t sufficient protection. Options start at least $40/user/year for nonprofits. You’re going to pay all that for something you hope to never use. Still probably worth paying for, like life insurance. 5. Ongoing Support Last, but certainly not least, you should be planning for the upkeep of your Salesforce instance, staff training and coaching, and updates and upgrades. The Salesforce platform is constantly growing and adding new features; likewise, your needs and circumstances are going to change over time. I strongly encourage you to think about growing someone internal who will devote a portion of their job to care-and-feeding of the system. I absolutely believe that any organization can grow this talent from within, as long as you have someone that is interested in the work and you give them sufficient time within their responsibilities. How much time to devote (what percentage of their job) is, of course, related to the complexity of your Salesforce setup and the parts of the organization it touches. If you can’t hire or grow a Salesforce administrator, you can contract with a consulting firm for ongoing support (often called “managed services”). Some consultants may sell a number of contracted hours for you to draw down over time. Others might let you simply pay for the time as you use it. I have set up contracts with several of my clients for a retainer where they get a certain number of hours per month at a discount compared to regular rates. Assume you’ll either have a staff member devoting between 25%-100% of their time or else contracted managed services from 10 hours/month or more. 💰TL;DR in ongoing support: At least one staff person devoting 25% or more of their time or else contracted managed services with a consultant. Bottom of the Bottom Line I literally started a blog to talk about how Salesforce is free like a puppy not free like a beer. You’re going to need to devote some resources to building, using, and maintaining a Salesforce instance, even if you never actually write a check to Salesforce directly.