Search Results

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

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

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

SALESFORCE IS FREE FOR NONPROFITS, RIGHT? ​Yes, but it's free like a puppy, not free like a beer. You might never pay for your user licenses if you are a small organization. But you’re going to need to hire someone with expertise to develop and run your system and you’d do well to explore some related tools that integrate with Salesforce. That’s still a pretty good deal! The purpose of this blog is to help nonprofits and educational organizations (and other organizations using Salesforce) get the most out of their investment. Lots of what I write will apply to for-profit Salesforce instances as well, but getting the most of Salesforce for nonprofits is my focus. ABOUT THE AUTHOR Michael Kolodner I'm a declarative Salesforce engineer and always excited to learn more about the platform. I love to help nonprofits use technology and data to work efficiently, solve problems, and make the world a better place. ​ In 2017, 2019, 2020, 2021, and again in 2022 I was recognized by Salesforce as a Salesforce MVP for sharing my knowledge, leadership, and creativity. ​ I also hold ten Salesforce certifications.

Latest Articles Michael Kolodner Feb 15 5 min Naming Convention Flows How to make text-named records have consistent and useful names. 197 views 1 like. Post not marked as liked 1 Michael Kolodner Feb 1 3 min One Form To Rule Them All Use a single webform for many uses with URL parameters and save yourself time. 168 views 3 likes. Post not marked as liked 3 Michael Kolodner Jan 26 1 min Sprinty's Community Resources Announcing Sprinty’s Community Resources, an online library of Salesforce content for nonprofits. 47 views 2 likes. Post not marked as liked 2 Michael Kolodner Jan 18 4 min i++ (or For Loops) in Flow How to create a For Loop in Salesforce Flow. (Increment a counter like i++.) 121 views 1 like. Post not marked as liked 1 Michael Kolodner Jan 4 5 min Dynamic Gauge: The First “Dynamic” Feature I’m Using I try out Dynamic Gauge Charts on Salesforce dashboards and then build and release tool to take advantage of them. 325 views 3 likes. Post not marked as liked 3 Michael Kolodner Dec 14, 2022 4 min Simple, Readable, Fun 🥳 - 💦 Sprinkle Emoji in your Salesforce ☁️ Adding emoji to your Salesforce aids in comprehension and adds fun! 👾 196 views 2 likes. Post not marked as liked 2 Michael Kolodner Nov 9, 2022 4 min Test Data in Production The truth is that we almost always have test records in production. So make them work for you. 107 views 1 like. Post not marked as liked 1 Michael Kolodner Oct 26, 2022 3 min Still Trying to Try Einstein My attempts to turn on and use Einstein Prediction Builder in two client Salesforce orgs. 114 views Post not marked as liked Michael Kolodner Oct 12, 2022 5 min Cheap (or free?) AI for Nonprofits? Is Einstein for Nonprofits really free machine learning for nonprofits? 236 views 4 likes. Post not marked as liked 4 Michael Kolodner Sep 7, 2022 4 min I’ve Got Admin Permissions–Now What? (Part 3) Part 3 of the series for accidental admins continuing their learning journey: Getting Certified. 56 views 2 likes. Post not marked as liked 2 Michael Kolodner Aug 10, 2022 5 min I’ve Got Admin Permissions–Now What? (Part 2) Want a superpower that you can get without being bitten by a radioactive spider? The Salesforce community is a superpower for everyone. 173 views 4 likes. Post not marked as liked 4 Michael Kolodner Jul 20, 2022 3 min I’ve Got Admin Permissions–Now What? (Part 1) Part One of a series about what to do when you become a Salesforce admin. 81 views 2 likes. Post not marked as liked 2 Michael Kolodner Jul 7, 2022 7 min FormAssembly Errors to Cases How to set up FormAssembly connector errors to become Salesforce cases for better tracking and accountability. 126 views 2 likes. Post not marked as liked 2 Michael Kolodner Jun 22, 2022 6 min Why I Love FormAssembly: The Prefill Connector There many webform tools that can integrate with Salesforce. But FormAssembly's prefill connector is a unique and powerful differentiator. 206 views 2 likes. Post not marked as liked 2 Michael Kolodner Jun 8, 2022 5 min My Favorite Way to Track Board Members How to conveniently use Salesforce and the Nonprofit Success Pack to track membership on your organization's board. 508 views 3 likes. Post not marked as liked 3 Michael Kolodner May 25, 2022 2 min When is a dashboard not a dashboard? Understanding what "dashboard" means in Salesforce compared to how you might use the term in your organization. 171 views Post not marked as liked Michael Kolodner May 11, 2022 3 min When is a report not a report? An introduction to all the amazing things you can do with Salesforce reports. 171 views 1 like. Post not marked as liked 1 Michael Kolodner Apr 27, 2022 6 min [Hard or Soft] Credit Where Credit is Due, part 2 Understanding hard credit and soft credit for donations in Salesforce and the Nonprofit Success Pack (NPSP). 323 views 2 likes. Post not marked as liked 2 Michael Kolodner Apr 20, 2022 6 min [Hard or Soft] Credit Where Credit is Due, part 1 Understanding hard credit and soft credit for donations. 471 views 7 likes. Post not marked as liked 7 Michael Kolodner Apr 6, 2022 3 min Why I Love the 50/50 Split The first of many articles about making your Salesforce pages functional and beautiful. 315 views 3 likes. Post not marked as liked 3 Michael Kolodner Mar 30, 2022 6 min Just Start Writing Last week in Documentation Done Cheap I suggested that you probably have access to a free way to house a Salesforce documentation wiki.... 274 views 4 likes. Post not marked as liked 4 Michael Kolodner Mar 23, 2022 3 min Documentation Done Cheap The best documentation is ANY documentation. Start with a simple Salesforce wiki. 381 views 3 likes. Post not marked as liked 3 Michael Kolodner Mar 16, 2022 2 min Crowdsourced Salesforce.org Price Guide One of the biggest benefits for nonprofits using Salesforce is the amazing discount. But it can be hard to find exact prices. 449 views 4 likes. Post not marked as liked 4 Michael Kolodner Mar 9, 2022 4 min Backup and Restore Let’s just acknowledge right now: Backup and Restore is like life insurance. You should pay for it and hope you never get more from it... 220 views 1 like. Post not marked as liked 1 Michael Kolodner Feb 23, 2022 10 min Nonprofit Salesforce – the True Cost of Ownership Breakdown of the real costs of implementing and maintaining Salesforce for nonprofits. 612 views 9 likes. Post not marked as liked 9 Michael Kolodner Feb 17, 2022 3 min Four Answers to “Why Salesforce?” Friends (and, of course, potential clients) often ask me, “Why Salesforce? Why should my nonprofit organization switch to Salesforce?”... 255 views 5 likes. Post not marked as liked 5 Michael Kolodner Jan 16, 2022 4 min My Salesforce Journey This wasn’t what I was going to be when I grew up. Not at all. I was going to be a diplomat. I was going to single-handedly negotiate an... 414 views 13 likes. Post not marked as liked 13

Privacy Policy I care about your safety, privacy, and security. I will never sell your data If you subscribe (using the signup form), I will only use the list to send notifications about this blog, such as new articles or announcements. If you ask to be removed, I won't retain any information.