Search Results

Last week in Documentation Done Cheap I suggested that you probably have access to a free way to house a Salesforce documentation wiki. Let’s talk a little about what to put there. 1: Just Start Writing I mean it! Don’t let the perfect be the enemy of the good. (Don’t even let the good be the enemy of the somewhat-adequate.) Any documentation whatsoever, even full of sentence fragments, bulleted lists, and typos is better than nothing. Even before you can start building specifics, you want to have some kind of guide for your users to understand what Salesforce is, why you’re using it, what assumptions are baked into your implementation, etc. You can polish later. But if you don’t get the basic foundation constructed early you’ll always be playing catch-up. 2: Basics: A Welcoming, Fun Roadmap Make the front page welcoming and make things fun! I like to adopt a fairly informal tone. It puts users at ease and helps them understand that this is a living document that needs their help to keep it up to date. If you can, put in pretty pictures. I like LucidChart to easily build a diagram of the relationships between database objects. I’m no graphic designer, but I think this is pretty good looking: Perhaps throw in some links to Salesforce’s documentation of the features you’re using. You can see, in this screenshot, that I literally start with a link to the NPSP documentation. Not that I expect too many users to follow that link. (Who are we kidding?) But I want to set the expectation that whenever possible I’m going to let Salesforce.org handle the documentation of their own features. (Pro Tip: Have you seen the amazing videos produced by the volunteer NPSP Videography Team? Whenever possible, include links to those videos to introduce your users to functionality from Salesforce.org’s products.) 3: A Page for Every Object Next I create a page for every commonly-used object. At first some of them (particularly the Salesforce standard objects) might seem kinda’ stupid. That’s fine. That might even be all there is to say at first. But pretty soon, you’re going to find ways to expand on this with commentary that is specific to your organization and your Salesforce instance. Better to give yourself the placeholder page right now. Eventually you’ll have time to expand to specifics: But far more important than those standard objects is to start recording your org’s custom objects. Hopefully a lot of them are just as obvious as Contacts, based on the object name and understanding your organization’s programming. But this is the place to call out all the assumptions on which your instance has been architected. For example, let’s say you have an object named Program Enrollment that is a child object to Contact and also child to Program. Most of us reading this blog probably understand that Programs should have records for every program offering of your organization. And having a Program Enrollment is the only way to know which contacts are part of those programs. And it, therefore, follows that only contacts for whom there is one or more enrollment record are “participants” in our program. Now is the time to write that out explicitly! If you have an enrollment, you’re a participant. If you don’t have an enrollment, you’re not a participant. It’s that simple. When someone comes looking for a report of “how many participants have we had this year?” it’s going to be much easier to answer that question for them if they understand in advance that “participant” is defined as “a contact that has a program enrollment.” Now they probably already know what reporting they need! So give yourself a page for each of your custom objects and, even if it seems obvious, be explicit about why they represent and how they are used. 4: Make a Web of Links Strictly speaking, I’m going to say this step is optional. But one of the main reasons I suggested in last week’s article that you should build a wiki is that you’re going to have an easy way to link your pages together. One page per object, like I suggested above, is easy to maintain and keeps pages short (so lazy people will read them). Certain objects get used together. So make it your practice to give internal links. Whenever you mention an object, make that mention a link to that object’s page. And when you add a new page for a new object, try to remember and go back to previously-created pages and add links to this new page. If your site builder allows for a hierarchical menu, take advantage of it. But if not, at least one page for each object is pretty easy to browse through. It sounds obvious, but it’s very helpful to your readers. 5: Clear Descriptions of Automation Automation is fantastic! Users love how it makes their lives easier. Automation is part of why I say that Salesforce can be custom software to run your nonprofit. But automation can also be pretty opaque. You might see part of what happens when automation runs, but other things that happen could be hidden, or at least not obvious. So give your users a way to understand what happens when they do something and why. It might make sense to devote a page of your wiki to describing automation. Or it might be better to integrate the automation documentation into the page(s) of the objects in question. But just get something written down so your users (and other admins, and even Future You) have some bread crumbs they can follow. List it all out: When the Enrollment Status field is changed to Withdrawn there is automation that creates a Task assigned to Reggie. This task is Reggie’s reminder that the student’s email account should be closed and the status of any outstanding tuition balances evaluated. As simple and understandable as that paragraph is, let’s point out that it does quite a few things: For users, it lets them know that changing the enrollment status field is the action that actually un-enrolls a student. (This should probably also be explicit on any pages about students, or programs, or contacts.) For Reggie, it’s documentation of how these tasks keep getting assigned to him. For the organization, it documents the things that need to happen when a student withdraws. For Salesforce admins, it documents that Reggie is explicitly built into the automation. If Reggie leaves, you are going to need to change the automation to point to his successor. That’s a lot in just two sentences! One final word: On pages focused more on the user than the system admin you might not use all the jargon about how the automation works. I wrote “there is automation” above. But if you're working on pages for sysadmins, you might want to say “there is a flow...” 6: A Page About Installed Packages Most orgs have several AppExchange packages installed in their system. Sysadmins will know how to go into Setup and see the complete list. But any apps that users will interact with may be worth explaining a little bit on the wiki (and linking to their creator's own documentation.) This is also a good place to give future sysadmins a little leg up in figuring out when and why you have installed one package or another. I could go on and on, but that’s really plenty to get you going, I think. There’s just one last thing: getting your colleagues to read your wiki. I’m not gonna’ lie: people are lazy. Most of the time they’re either going to ask you directly for help or their going to just not do the thing they can’t remember how to do. I can’t beat human nature. But I can make it easier for you to answer their questions! Be Relentless: Every single time you answer a Salesforce question, do so by giving a link to the page on the wiki that they can reference in the future. (If you have to, write that page quickly and then link to it as though it was always there! I won't tell.) Relentlessly mention and link to “the wiki. The wiki. The wiki.” It takes time, but people will start to realize that when they ask you a question they’re likely to get a link to the wiki. Eventually, they'll even look at it for themselves. Make It Easy to Find: It’s one thing to link to the wiki in emails and Chatter posts. But if you really want your users to start going there on their own, you have to make it easy for them to find. Put a link front and center on the homepage so they see it every time they log in. In Lightning you can even customize the help menu (question mark) so a link to the wiki is available no matter where people are in Salesforce: And every time you do any sort of training, point out to people that a link to the wiki is there in the help menu. Once your users catch on, you might even find that your “Salesforce wiki” morphs into your “Organization Handbook.” How great is that?

There are a million different ways to make documentation for your Salesforce instance. I’ve seen demos of Spekit and Elements.cloud and I really do think they’re super cool. As I recall, both give very nice discounts for nonprofits, too. But I’m just too cheap to want to pay for more things if I can get by without them. And given my client base (small nonprofits), the fewer paid apps I can recommend, the better. And let’s face it, for most organizations any barrier to writing up good documentation, no matter how small, is just going to mean no documentation at all. And I consider that unacceptable. So if you aren’t going to pay for a really good documentation solution (or aren’t going to pay for it right away) what is the responsible Salesforce admin to do? (Note: I don’t really consider it “responsible,” to make a pile of Word documents, PDFs, or even Google docs. I’ll grant that getting something written is better than not writing any documentation at all. And the Google docs folder at least can be somewhere owned by the organization and they can have links between them. But really, a pile of Google docs is not super convenient.) 📑 What you need is a wiki. 📑 Don’t let that name intimidate you. A wiki is simply a collaboratively managed and edited website. That's what you want to document a tool (Salesforce) that you’re all going to use together. You want it collaborative because you want input from users, executives, your Salesforce admin, consultants, etc. Sure, most of them might rarely add to the wiki, but the very idea that they can and should contribute is empowering. And other than the fact of it being online and being collaboratively edited, there’s nothing special about “a wiki.” It doesn’t have to be created using special software. (Even that aforementioned pile of Google docs could probably be considered a wiki.) Don't think Wikipedia, think whiteboard. And guess what? If you’ve got Google docs then you have Google Sites. Both are a standard part of Google Suite (now called Google Workspace), which is free for nonprofits. (That’s my kind of pricing!) Know what you can do with a Google Site? That’s right: You can create a wiki! In under a minute you can create a new Site with a simple template and just start adding pages to it. Sites is easy and fast to use, and it even does a pretty good job making a menu as you add new pages. I see no need for anything more “wiki-ish” than that. If your organization doesn’t have Google Suite…I’m sorry. It’s not that I have a particular love for Google. (I don’t.) But in my experience if you don’t have Google, you probably have Microsoft 365, and that makes me sad. Again, nothing against Microsoft per se, it’s just that apparently starting any kind of site/intranet/wiki seems to be much too difficult on Sharepoint. Once the Sharepoint site exists, it’s fine. I suppose there are some of you reading this that have access to neither Sites nor Sharepoint. But ask around a bit and you might find that there is some kind of website building tool already available within your IT services. Don’t be picky. Just two criteria matter: 1. Is it free? 2. Can I easily create multiple pages (with simple text and images)? This week we’re stopping here: You’ve identified that your organization has some kind of tool that will allow you to create a basic website with multiple pages. Your homework is pretty simple: Create your site. (Name it something like “[my organization]’s Salesforce wiki.”) Create your first page. Give it a title and some placeholder text. Set the sharing/visibility settings to at least allow anyone from your organization to see the site with a link. Open to anyone with the link is OK, in my opinion. Extra Credit: Create one additional page of your wiki so you can see how the tool creates a menu. Next week: My simple tips for building out your documentation wiki and driving users to it.

One of the biggest benefits for nonprofits using Salesforce is the amazing discount we get on state-of-the-art software. The same software used by Fortune 500 companies, at levels of discount usually reserved for their biggest/best customers, without having to actually negotiate for that discount. I think that’s a pretty good deal. But if you’re a nonprofit leader considering Salesforce for the first time (or considering changes to your implementation), it can sometimes be frustrating trying to figure out the specifics of what you’re budgeting for. If you know you’re going to need logins for 37 employees, you want to know how much you’ll be paying for the 27 logins you’ll need after the 10 donated licenses. [Spoiler alert: $432 * 27 = $11,664/year] (But don’t forget that licenses are not your only cost!) For several years I’ve been loudly advocating for increased price transparency from Salesforce.org. There have been some horrendous cases of nonprofits overcharged because they didn’t know what they actually needed. And even in the case of organizations that knew what they needed and what the right price was, sometimes it’s been hard just to get things properly provisioned. 📣 I've been loudly advocating for increased price transparency from Salesforce.org Credit where credit is due: Salesforce.org (SFDO) has made strides to get better. I haven’t heard recent horror stories of overcharges by Account Executives. SFDO reorganized part of their website and published this pricing guide, for one thing. But in my humble opinion, a PDF pricing guide is not the most convenient format. And there are plenty of products left out of the guide, particularly the newest and shiniest things Salesforce has released in the last few years. So that’s why even after the pricing has gotten more transparent, I’ve continued maintaining the Crowdsourced Salesforce.org Pricing spreadsheet. Even if most of the information is available on Salesforce’s website, this way we can see everything in convenient tabular black and white without fishing around various parts of Salesforce.com and Salesforce.org. Go ahead and bookmark that sheet, you'll probably want to refer to it. And if you have any information to add to it, or questions about what’s there, feel free to tag me in a comment–I really do want to keep it up to date. ✅: Bookmark the Crowdsourced Salesforce.org Pricing Guide 🔖 What I would really like to see someday is a statement from Salesforce along the lines of “any organization qualified for the P10 grant will also be able to purchase any other Salesforce product at a minimum discount of X% off list price.” I know that won’t be able to apply to all products, or that some may take time after release to be added to SFDO’s pricing. But if we knew that was the baseline it would make it so much easier for nonprofit admins to think about all the new toys Salesforce announces. Unfortunately, I don’t seem to have made any progress toward getting a guideline like that. If you have ideas for how I could make that wish come true, please get in touch!

Friends (and, of course, potential clients) often ask me, “Why Salesforce? Why should my nonprofit organization switch to Salesforce?” I’m the first to admit that Salesforce is not the only option. It might not even be right for your organization. But I’m a Salesforce expert and I choose to be a consultant on the Salesforce platform. If you want to use another system, do so with my blessing. (I just won’t be able to help.) And let’s not lose sight of the fact that a young (or tiny) organization might not even be ready to graduate from spreadsheets. As long as you’re able to get your work done, that’s the most important thing. Your nonprofit exists to make the world a better place, fulfilling your mission with your program. I would much rather the mission get moving than your systems be perfect. As I see it, there are four main reasons that I recommend nonprofits and educational organizations use Salesforce. 1: You’ve determined that you need “A System” If you have reached the point that you’re considering hiring a consultant like me, that usually means you’ve figured out that you need a little more organization, a little more data security and integrity. You’ve realized you need “A System.” That’s good! It’s a sign of organizational maturity to even have a moment to step back and think about how to do the work rather than always be consumed with just doing the work. 2: Salesforce's 1-1-1 Model The next question, then, is why I work with Salesforce and why I recommend it to nonprofits that are ready for a system. It’s not just that Salesforce is “free.” (The whole point of this blog is that Salesforce is “free” like a puppy, not “free” like a beer.) What makes Salesforce so interesting for nonprofits is their 1-1-1 model, or what they now refer to as Pledge 1%. From its founding, Salesforce dedicated 1% of the company’s equity, 1% of its product, and 1% of employees’ time to nonprofits. Of course, as Marc Beniof has joked, in 1999 they had no product, no employees, and a company worth nothing, so that was pretty easy to pledge! But more than 20 years on that promise has some real…well…promise. Eventually, the “1% of product” portion of the pledge came to mean that any nonprofit can receive a permanent grant of 10 user licenses, or logins, to a Salesforce instance. The application process is about as simple as waiving your IRS 501c3 determination letter (or international equivalent). Then you’ll get your ten licenses approved. This is known in the ecosystem as “the P10 grant.” And that’s a pretty big benefit. It’s a 100% discount compared to what for-profit organizations pay for the exact same software platform. For licenses beyond the 10th, the discount is approximately 75% off list price, with no need to negotiate. Considering that most nonprofits have fewer than ten employees, most will never send a penny to Salesforce itself. I think that’s a pretty good deal. 3: “Dot Org” and NPSP Salesforce.org (SFDO) is an arm of the company dedicated to working with nonprofits. “Dot Org,” as it’s known, developed the Nonprofit Success Pack (NPSP), an app installed into your Salesforce instance that modifies the platform to work more like a nonprofit fundraising database instead of a sales tool. (SFDO also publishes the Education Data Architecture, which is a similar product built for educational institutions.) SFDO also supports the nonprofit community with training materials, continues to develop additional products, and more. So nonprofits aren’t just using the product that’s developed for business, we get products developed for our special use cases. 4: Custom Software to Manage Your Mission But fundamentally, I recommend Salesforce to nonprofits because you’re getting access to a state-of-the-art software platform that’s easy to customize to do exactly what you need. With a little bit of implementation know-how or help from a consulting partner, you get custom software to run your organization. Not too long ago anything custom or personalized would have meant a minimum investment out of the reach of all but the largest nonprofits. And once that money was spent, you’d be stuck with that system unchanged for years, even decades. But now even the smallest organizations have access to Salesforce. And once you’re on the Salesforce platform, you benefit from new features and innovation that Salesforce is constantly developing, with much of that new goodness coming your way for free. Plus you can get help and support from thousands of people in the nonprofit Salesforce community. And that is the not-so-secret Fifth Why! #Donation #System #CustomSoftware #Customize #Nonprofit #WhySalesforce

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 end to the Arab-Israeli conflict. Now I design software systems for nonprofit organizations. How did I get here? Like so many others in this ecosystem, I’m an “accidental admin.” (And yes, I understand why a lot of people don’t like to use that term.) Databases followed me for decades. I just kept running away from them until I stumbled on Salesforce. In my early career I always seemed to be the person in the office that took a look at the way we were doing our work and decided that we needed systems to make us more efficient or more organized. At a small magazine publisher outside Boston I implemented an editing and production software package that had literally been sitting on a shelf unused. At the Federal Emergency Management Agency (FEMA), I battled Microsoft Access to make our office a shared database for case management in the Office of Congressional Affairs. And at the Department of State, in the immediate aftermath of the 9/11 attacks, I worked to build a system for tracking hundreds of countries’ offers of aid and assistance for a daily update to senior policymakers. Even during the decade I was a stay-at-home dad I found myself deeply involved in the VoteBuilder database as I volunteered with political campaigns and in charge of the membership database for Beachcomber, our co-op swim club. Every system I worked with just felt like a slog. They were fighting my attempts to make them understandable or easy to use. “Pretty” wasn’t even on the menu. In 2012, I returned to the work world in a newly-created community organizing capacity at Reconstructing Judaism. It was clear from the first day that we needed a database to track the congregations that were our members. Someone had thrown together an Access database before I arrived, but we needed something better. We needed a “CRM,” or constituent relationship management system. I hadn’t heard the term, but it encapsulated what I had been working with in all those previous positions. And since I was the youngest and the most tech savvy, the search for the CRM ended up on my plate. That’s when I learned about “this Salesforce thing” and that, thanks to the 1-1-1 model, it was “free.” That seemed like a good deal! Plus it was super simple for me to spin up a fully functional trial instance to see how things worked. Unlike all the systems I’d tried before, Salesforce somehow made sense. With just a few clicks I was able to customize it to work more like what we needed. And the user interface (both front- and back-end) was intuitive. Hooray! We compared a few other options and then chose Salesforce. Using an implementation partner, we got up and running in just a few weeks. Then I started seeing what more I could learn about how to make Salesforce even more custom for us. The next major step in my journey was discovering the Power of Us Hub, the online community for nonprofit Salesforce users. When I was first starting to administer our instance, I wasn’t confident I was doing things right. I started asking questions on the Hub and immediately found a community of nonprofit Salesforce practitioners that were incredibly generous with their time and their wisdom. They validated when I was on the right path, guided me back if I wasn’t, gave me tips, tricks, and best practices, and were genuinely warm and welcoming. That’s what really drew me in. I also started joining the wider Salesforce community. (This was all before the creation of Trailhead. That’s one more amazing resource if you’re new now.) As my knowledge grew, of course, I started answering questions on the Hub instead of mainly asking them. But I still ask a lot of questions even today. It’s how I learn! I am a firm believer that there is no such thing as a stupid question. I think it’s terrific when someone has the courage to ask for help. And I’ve found that the Salesforce community is incredibly welcoming and happy to answer questions, even ones that have been asked before. Fast forward a couple of years and I decided I was interested in making Salesforce the main focus of my next job. I found a full-time solo admin position at Spark, a mid sized nonprofit that was supportive of my continued growth as a Salesforce professional. My position at Spark allowed me opportunities to participate in Open Source Sprints, present at community events, and even to travel to Dreamforce. All that meant meeting more people within the community. I made friends that I know I’ll keep for life. In 2017 I was honored to be named a Salesforce MVP. That’s been a further chance to meet friends and gain insight into Salesforce, the platform as well as the organization. The most recent step in my journey is that in 2020 I made the leap to self-employment as an independent Salesforce consultant. Now I get to work with many nonprofits to build and support their Salesforce instances. My favorite work is creating custom program management solutions that let organizations run their unique programs exactly how they need. #AccidentalAdmin #CareerJourney #PowerofUs #SalesforceAdmin