Search Results

Salesforce has two options for object records: they can either have a text Name field or be auto-numbered. Accounts, of course, have an Account Name field. Contacts, technically, only actually require LastName, which is obviously text. Opportunities are named. Payments (an NPSP object) are auto-numbered. Auto-numbering is nice because nobody has to think about it, but it’s kinda’ impersonal. Text fields, however, can be the Wild Wild West. If you’ve spent any time in Salesforce, I bet you’ve already encountered this with Opportunities. Some organizations train people to stick to a standard, but more often than not even adherence to a policy is spotty. You can end up with an opportunities list that is just impossible to sort through, whether it’s opps that all have extremely similar names or each has a very specific name that somebody painstakingly typed in, whether or not it gives all the information you might want at a glance. (And these were examples from Opportunities, which already lend themselves to some structure around naming!) We Need Naming Conventions Sometimes we need records where the name tells us something but where it would be annoying to make your users type it in. We need naming conventions. For example, I have clients creating records of students applying to colleges. Wouldn’t it be great to be able to glance at a list view and know most of the important information about that record? Something like: Harry Potter - Wizarding U - SY24 - Waitlist Hermione Granger - Wizarding U - SY24 - Accepted It would be bad enough trying to get users to type all of that. They would never be consistent with school names or school years. And they would definitely not keep the stage up to date! But thanks to Flow, it’s also not very hard to do it for them. Build a Naming Convention Flow These are some of the easiest flows you’ll ever build. Take the example of the college application tracker: You can actually just have one step: This is a Before Save flow (the setting in Flow Builder is “Fast Field Updates”), which means it runs before the record is even saved to the database and it runs very fast. In this case all you have to do is assign a new value to the Name field of the record. It’s going to overwrite whatever value was there with the most up-to-date information. This kind of naming convention is really easy and helpful for all sorts of objects. I use it regularly for applications, report cards, test scores, financial aid awards, and the like. If you want to impose a naming convention for opportunities, you might want to build in more logic, perhaps distinguishing between naming for individual gifts, corporate gifts, recurring donations, etc. That takes a slightly more involved flow, but there’s really nothing too complex here. It’s just a handful of decisions to decide the type of gift and then use the right naming based on that. So we’re done! Build a quick flow that updates the name–probably in a before save context–activate and move on. One Small Gotcha - The New Button I do have one pet peeve related to this: The Name field is still going to be required when you click New. 🤦 A really conscientious user (my favorite kind!) is going to see the required New College App field and type out something that matches what they’ve seen in other records of this kind. And they’re going to hate that they have to type so much. A not-conscientious user, of course, is just going to put the name of the school, or the student, or the year, but definitely not all three. You can teach people they can just put anything in the field and it will be overwritten, but that offends my sensibilities on more than one level. (Not how it works in other places. Not a good habit to get people into. Unnecessary extra typing...) And you can’t even give any sort of on-screen hint about this. (You can't put help text on a Name field. Probably nobody would read it if you did.) So you have a few choices here, none of which make me happy. Training - Just tell people that for the object in question the name field is going to be overwritten and they should put any character in that field and move on. I don’t love this option because it relies on them knowing to ignore the field in this case but you probably don’t want that kind of behavior in other places… You can make things slightly better by setting the record Name to be “_object name_ (filled by flow)” or the like. But then "(filled by flow") is also going to show up in the headers of your reports and list views, which I kinda' hate. A Quick Action - It’s very easy to make an object-specific Quick Action and then remove the standard New button on related lists. The benefit of an action is that you get a custom mini Page Layout for the action and you can remove the name field from that layout (which you can’t do from a regular page layout that would be used for the New button. You can also remove other fields that are perhaps not relevant at the moment of first record creation and can prefill fields to save your users time. My disappointment with this approach is that you can’t actually have this new action override the New button in related lists. This new action will show up at the top of the page on the parent object, next to the Edit button and the like. You have to remove/hide the New button on the related list. I think it’s confusing for users that some related lists have New right in context on the list and for others you have to look elsewhere on the page. Is this a huge deal? No. Is it poor user experience and user interface design, yes! And by the way: Your Quick Action will be used when creating a record from the related record’s page. But not if you click New on a List View… A Screen Flow - If you want to get really fancy you could make a screen flow for creation of new records. Like with a custom Action, you don’t have to ask users for the Name in your screen flow. It’s then possible to create a new list button and reference the flow’s API name as a URL. (/flow/FlowAPIName?InputVar1={!Mergefield1}&InputVar2={!Mergefield2}etc…) Then you can use that list button to override the New button both in list views and related lists. By default a screen flow isn’t going to redirect to the created record. (There are ways to fix this using UnofficialSF components, but still…) The screen flow is going to look different than other New button behavior. And the screen flow is also going to run more slowly. Let's also not forget that building a screen flow takes more than a little work, even for a simple one, and leaves you with yet one more custom thing to maintain. In real life I’ve usually gone with option #2, but sometimes just lived with #1. Option #3 just feels bad all around.

One of my favorite ways to bring the programmer’s mantra of Don’t Repeat Yourself! (DRY) into my Salesforce work is to build the One Form To Rule Them All. By playing with URL parameters you can take a simple form and use it more than once. A single Field Trip Form that can be used for any and all field trips throughout the year. A single Pre/Post Survey A multi-purpose Waiver form And so much more. The trick here—the little mental shift that can really open up possibilities—is that “questions” on the form can be used as the text or content. Let me say that again: Questions on the form can be text, instructions, or content of the form, rather than something you are asking the user to fill out. Then you put the values you want in those questions into the URL that you send out and—BAM!—the form is customized. Saves time (and time is money) building and managing webforms. Works with Any Form Tool You should be able to do this with just about any form tool because all you’re using is URL parameters. My tool of choice is usually FormAssembly. But URL prefill is pretty standard functionality and should be available with most form tools. (I’ve written here about FormAssembly’s prefill connector and the amazing powers it can bring to bear. But that’s not what we’re doing here.) The Master Field Trip Form Let me use The Academy Group to show an example. They take their students on lots of field journeys and they want to get consent each time, notifying parents/guardians about where the kids will be and what they’ll be doing. It was such a pain to create a whole new form for each trip. But now they have the Master Field Trip form. All they have to do is customize the URL they’re sending out and the form works for every trip. I have a simplified example form for us to look at in my FormAssembly account. If you go to the form without anything added to the URL it’s not very useful. But if you use this format to customize the URL you can do all sorts of things: https://www.tfaforms.com/5037437?tfa_1=[reason for trip]&tfa_23=[location] Replace the bracketed sections with your desired text and it goes into the fields. (The tfa_# references tell the form which questions to put the text into. You’ll have a similar syntax for other form tools.) You can fill more than just two fields if you need to. (URLs do have a maximum length of 2,048 characters, so don’t write a novel in your prefill. But if you’re being reasonable you can do quite a lot.) Here’s an awesome field trip that I would highly recommend based on my own recent travels. The URL is: https://www.tfaforms.com/5037437?tfa_1=To see the ice cave, learn about the unique geology of Iceland, and get an introduction to the Northern Lights. We will eat lunch in the rotating cafe with a view overlooking the city.&tfa_23=Perlán Science Museum, Reykjavik, Iceland But you can use the same form for a more realistic trip. This URL is: https://www.tfaforms.com/5037437?tfa_1=To visit a local business.&tfa_23=Mike’s Sandwich Shop, 123 Main St. ) You can create all sorts of waivers, permission slips, and notifications this way. Pre/Post Survey In One Now let’s look at one more example that can really save time: Use the same form for both a pre- and a post-program survey. To measure program effectiveness you usually want to ask program participants the same questions before and after, in order to measure the effect of our intervention. You might think you would want to build two different forms for this. But Don’t Repeat Yourself! If you have two forms and then you decide to add a question, you have to modify two forms. Instead, if at all possible, I want to use the same form for both pre and post. All that’s going to take is: A dropdown menu question for Pre or Post. (You can probably hide this question.) Setting the value of that question via the URL. (Optional) Conditionally hide or display different instructions or even questions that are used only in the pre or post context, questions based on the value of Pre/Post. See what I mean here. Don’t Repeat Yourself in the Connector Either I don’t want to go too deeply into the step of sending your form data to Salesforce. In fact, this trick doesn’t necessarily assume you’re doing anything more with your form data than having the responses sit on your form provider’s server. But if you are building a connector to send the data into Salesforce, keep the same DRY principles in mind. You can map the question that you prefilled into the created record, for example, as the name of the field trip this permission was for. Or if you need a more succinct name, you could use an hidden prefilled field (“Perlán Trip, Iceland.")

I'm excited to share with you that a new resource launched today, created and maintained by Open Source Commons volunteers. Sprinty's Community Resources is an online library of crowdsourced community content for nonprofits and educational organizations using Salesforce. It's a fast way to find articles and How Tos that others have found useful in the past. Resources submitted by the community are searchable and sortable so you never have to wonder "Is there are good article about the true cost of Salesforce for nonprofits? Where could I find that link?" Of course, you can also just browse through the listings to learn all sorts of things. And best of all, you can contribute more resources to the list! Simply click on the submission tool and fill out a quick form with a link to whatever podcast, blog post, article, or video you've found helpful. Each resource is reviewed by a volunteer "curator" to ensure quality content is featured on the site. Sprinty's Community Resources has a Trailblazer Community Group if you want to stay in the loop on updates and ask questions. This project wouldn't have been possible without the vision of Jodi Nemser-Abrahams and Rebecca Tasetano and the input of a team of dedicated volunteers I'm proud to call my colleagues and friends: I hope you, too, will add to the resource collection and even consider getting involved with the team!

If you’ve learned any programming (in just about any language) you’ve learned about For Loops: For as long as (i is less than (the point I want you to stop at) ) do something. It’s how you do something X times. (Really, i times, but you get me. 😉) Like print out your name 1,000 times so it fills the screen. Really common in programming and pretty easy. And perhaps not that useful, but it definitely has its moments. But guess what’s not straightforward in Flow? Flow loves to do loops over collection variables, where you already have the records you’re going to work through and do something about or to each of them. Most of the time that’s what you’d want to do in a flow, sure. But what if you want to do something a particular number of times? Super easy in programming, not straightforward in Flow. There’s no simple Flow equivalent of “i++”, the syntax for incrementing a counter to control your For Loop. If you make a flow collection variable that holds numbers, which you could technically loop over, you would have to add each number to that collection. The work of doing that would be more effort than it's worth. Maybe when you get a new volunteer you want to automatically set up ten check-ins with them to see how their volunteer journey is progressing? Or a table sponsorship entitles the purchasor to 11 additional guests at the gala, for a whole 12 seat round table. There are all sorts of reasons you might need to either do something X times or create X of something. Let’s look at how you can actually accomplish this in flow. We’re going to look at an example that does something ten times. You could easily replace ten with any other number. 1. The first thing we need is our counter. That’s going to be a number variable that we’re going to use to increment. I’ve called mine “i” for the purposes of this blog. But I will note that my normal naming convention for variables in flow is to start them with “var.” So in real life I would call this something like “varCounter” or “varIterationCounter.” But in programming a For Loop we would use just i, so that’s how I’m showing it here. 2. The first actual step in the flow (or this loop portion of the flow) is a Decision. You have to check if your counter has reached the stopping point. We want to see if i < 10 or if it has reached 10 or more. Note: I started my counter, above, at zero, so I have to stop one lower than my desired number of iterations. Computers like to count "0, 1, 2, 3, …" If you reach 10, you’ve done something eleven times. If this confuses you, you could start your counter at 1 instead of zero (set the default above to 1, rather than 0.) You also could start a counter at the top and work your way down. That would be i-- rather than i++, which is totally acceptable though less commonly used. (Also, by the way, word processors really want to autocorrect “i minus minus” into “i em-dash.”) 3. If we are still in the loop (our counter has not reached 10), then we “do something” and iterate our counter. (This would be the code block within the For Loop.) The “do something” part of your flow, of course, depends on what you need to do. For our example we are making a flow that will create 10 accounts, so we have to assign a record variable for one of those accounts. To iterate the counter you are going to use an Assignment element to add 1 to the variable i. (I know I said that Flow doesn't do i++, but that's exactly what this step is doing. It just doesn't read that way.) 4. Then we have to add the account record variable we just assigned to a collection variable (for insertion later.) You can actually use a single Assignment step to both add the record variable to the collection and to increment the counter. But I wanted to show the entire idea diagrammed out. Also: You can not assign your record variable's fields and assign that record variable to the record collection variable in the same step. That will not work. 5. We loop back to the decision element to see if we need to do this again. 6. If we have reached the limit, then we break out of our loop and use the Create Records element to actually put 10 new accounts into the database. Et voila! Here are all the accounts that were in our collection variable now available in the database. Summing it all up, here’s the most simple representation of what we’re doing, though for it to work in Flow you need at least one additional assignment element, as I noted above. Once you know how to do it, this is really not such a big deal! But if you're new to Flow or haven't needed to solve this particular challenge before it takes a moment to puzzle it out.

One of the most important things I do with FormAssembly is make sure that when there are errors sending data to Salesforce we don’t lose track of those problems. That was important for me as a solo admin but it's perhaps even more important as a consultant supporting multiple organizations. When there is a connector error you want to make sure that the right person in your organization sees it and can deal with the problem. Sometimes you might even want to be able to assign different kinds of errors to different people, either by which form they come from or based on some other criteria. And you want to be able to document and report on how you or your team are ensuring that the data coming from FormAssembly is working right. There’s a really convenient way to set this up: Email-to-Case. Email-to-Case is a standard Salesforce feature that allows messages to a particular email address to automatically become case records in Salesforce. It’s very easy to set up and doesn’t require any extra licensing for nonprofits on the P10 donation. Once email-to-case has created a record you can use all the other features of Cases, including setting up rules for who is assigned the case, tracking them through stages until they are completed, collaborating via Chatter, etc. Many organizations don’t use cases because they aren’t engaged in customer service type support, so the object is just sitting unused. This makes it perfect for collecting and organizing your FormAssembly connector errors! But if you’re also using Cases for other things, it’s certainly possible to use it for FormAssembly at the same time. Here are the steps to get yourself set up to monitor FormAssembly errors via Case: 1. Set FA to send alerts to someone in the organization. This is probably the most important step. In fact, even if you aren’t using email-to-case, make sure you follow this instruction! New accounts ought to be set up this way by default, but that isn’t always the case. I have alerted FormAssembly Support to this problem but I’m not sure if it’s fixed yet. (I haven’t created a new FA account in a little while.) In your FormAssembly account, go to your profile>General Settings and check “Notify me of any downtime or processing error regarding my forms.” As I said, this ought to be checked by default. If it’s not, then when a form has an error, it fails silently. Yikes! With the box checked, the FormAssembly account user is going to get emails whenever there is an error that prevents a connector from sending data to Salesforce. (Note: If you have an Enterprise FormAssembly account with multiple logins the errors will go to each form’s owner. You’ll need to tweak the instructions here to account for that difference or else set all forms to send their errors to the same person.) Of course, if you’re the form builder and the Salesforce admin, you might just figure getting those emails is enough. You can see them in your In Box and deal with them when they occur. But perhaps you like to go on vacation? Or perhaps you’re the form builder but not the FormAssembly account holder, so the emails don’t go to you? Also, using your In Box as your To Do List is not necessarily the most convenient for all sorts of reasons… 2. Make An Error Form In order to test our setup and to help us as we build it, we’re going to make a FormAssembly form whose entire purpose is to cause errors when it’s submitted. (It should be obvious that we’re never going to share a link to this form to anyone else.) I literally name my form “Exists only to trigger connector errors.” That way I feel there’s little likelihood of someone misunderstanding how this form is used. It’s a pretty simple form, too. Basically it just has a submit button: You can set up the connector in all sorts of ways. (It’s not that hard to figure out something that will fail.) Here is an example of trying to find and then update a contact with no last name. Because Last Name field is always required for a contact in Salesforce, this is guaranteed to fail. Now test out your form to make sure that you get an email about the connector error. (If you’re not the one error emails go to, warn your colleague that this error is on the way. It might be helpful for them to forward it on to you.) 3. Set up On Demand Email-to-Case In Salesforce go to Setup>Service>Email-to-Case. Check Enable Email-to-Case and Enable On-Demand Service. Then click New under Routing Addresses. Give a name (your choice). Put in the email addresses you want to accept cases from. For this purpose, we need to accept from support@formassembly.com and from the email address we’re going to forward errors from (yours, or the FormAssembly account holder’s). [See the note in the next section that you might also need to accept from a temporary verification address.] When you click save, you’ll get an Email Services Address that is the name you gave plus a long string of characters. That’s the address you’re going to send emails to that will result in cases. You can try this: Send an email to that address. Load the Cases tab and see that a new case has been created. 4. Set Up Email Forwarding Whoever is now receiving the error emails now needs to set up their email account to forward those error emails to the Salesforce email-to-case address that you just created. Specific instructions for setting up forwarding rules vary by your email provider, so they’re outside the scope of this post. But it’s generally pretty easy to figure out. You just set a rule that all emails like the one you triggered from FormAssembly should automatically be forwarded to the email-to-case address (and probably immediately removed from the In box, since you’re going to be keeping track of them elsewhere). One thing I’ve learned the hard way: If you want to set Gmail to forward you have to first send a verification email to the account you’re going to forward to. That verification email will come from forwarding-noreply@google.com, not from the person/account that will be doing the forwarding. (It took some frustrating hours to realize that!) So when you’re setting up which addresses Salesforce should accept email-to-case from (Routing Addresses), you have to watch for that email. Once you get the forwarding set up, the messages will come from the original sender (support@formassembly.com). Now, you should be able to trigger an error from your errors form and see that a case gets created in Salesforce. Voila! Theoretically you’re done now. But you might notice that the case subject is pretty generic. We can do better than this! Let's see how to make these cases a little easier to work with. 5. Set up cleaning up of the case when it’s created The case created by email-to-case is going to be pretty generic because the FormAssembly error emails always have the same subject, like this: FormAssembly / Salesforce Connector Error Report - 06/12/2022 01:45:49 PM The body of the email tells you the name of the form and has a link to the response that errored. But it would be nice if your case had the form name in the Subject so you could easily distinguish them, wouldn’t it? Flow to the rescue! We’re going to build a simple Salesforce Flow that runs whenever a Case is created and is set for Fast Field Updates (which means it runs Before Save). The first thing this flow does is check to see if the case subject contains “FormAssembly / Salesforce Connector Error Report,” to know if we need to do the other steps. Then it’s going to replace the subject with a formula that parses the email body to find the name of the form that triggered the error: /*Give me a section from the middle of the Description field*/ MID({!$Record.Description}, /*starting 11 characters past the first character of the substring "your form "*/ FIND("regarding your form ",{!$Record.Description}) + 21, /*and ending just the right number of characters later. 22 leaves a quotation mark. So do any other numbers I've tried, so we'll just have an extra step to remove that quotation mark. */ (FIND("WHAT HAPPENED",{!$Record.Description}))- (FIND("regarding your form ",{!$Record.Description}) + 22) ) Then the final step is to clean up the text of the subject because the all-text email has some Unicode instead of characters, like ")" instead of ")". This step also grabs the link to the FormAssembly response and puts it into a URL field we’ve created on Case. I use five formulas for this. They’re a bit of a pain to read if you’re not familiar with Salesforce formulas, but you could just copy/paste and they’ll work: Here’s the formula for formulaFormResponseURL /*Give me a section from the middle of the Description field*/ MID({!$Record.Description}, /*starting 2 characters past the first character of the substring "The following response was received, but could not be processed using the Salesforce Connector:" which is 95 characters long*/ FIND("The following response was received, but could not be processed using the Salesforce Connector:",{!$Record.Description}) + 96, /*and ending just the right number of characters later https://powerofus.force.com/0D58000002e7nDy?fromEmail=1&s1oid=00D00000000hWLM&s1nid=0DB800000004Fa7&s1uid=00580000009bjBJ&s1ext=0&emkind=chatterCommentNotification&emtm=1461274144137&OpenCommentForEdit=1 */ (FIND("The error was:",{!$Record.Description}))- (FIND("The following response was received, but could not be processed using the Salesforce Connector:",{!$Record.Description}) + 97) ) Here’s formulaRemoveExtraQuoteInSubject: SUBSTITUTE({!$Record.Subject} , '"', '') And here’s formulaReplaceCloseParenInSubect: SUBSTITUTE({!$Record.Subject} , "(", "(") [The formulas for for OpenParen and Hyphen are the same as CloseParen but use ) and -, respectively.] 6. Set up a case assignment rule to assign cases to the right person/people Now that you have a case that’s organized and readable, you can set up a case assignment rule. Of course, if you’re a solo admin and the sole form builder, you might just assign all cases to yourself. But as your organization grows or others learn to work with FormAssembly you can use Salesforce’s standard case assignment rule functionality to share cases among a larger team. 7. Set up a case assignment email template I tend to assume that people (including myself) won’t remember to go looking for cases without a reminder. So you can set Salesforce to send an email to the case owner whenever there is a new case. The first step in that is making an email template. It doesn't have to be anything fancy, just the most pertinent fields (Subject, Status, Description) This email is going to go out to remind you (or whoever gets form cases) that you have a form error case to deal with. But because we have also created the case, this email is not the only record of the problem. Someone else could look in on cases to see what errors are still unsolved. 8. Set up a case assignment email alert Then use that email template in an email alert. 9. Have flow send an email Finally, set a Flow that will send out that email alert to the case owner upon the creation of a case.

There are lots of webform tools in the world. If you only need to collect information from people and store that information in Salesforce there are many tools that can do it. Even if you don’t have the tool integrated to Salesforce, it would be pretty easy to import a spreadsheet of the responses. But if you ask me to recommend a form or survey tool, I’m going to steer you to FormAssembly. [Full disclosure: I am a FormAssembly partner, but I do not get any kind of compensation from them for that. It just means I can give a discount code to my clients. I don’t get anything in return for a client purchasing through my code.] If you’re making only very simple forms, you’ll find FormAssembly easy to use. But you might do just as well with Google Forms (ugly, though) or you might even prefer something like GetFeedback, which makes fast and pretty customer satisfaction-type surveys. It’s when you want to make your forms more interactive that FormAssembly really shines, and that is due to the feature they call their Prefill Connector. If you have FormAssembly at the Premier level or above, you can have the form talk to your Salesforce data before the user begins to interact with the form. This is a neat trick that few, if any, other webform tools can match. URL Prefill The Prefill Connector is not URL Prefill. It's so much more. Just about any webform tool can handle what is called URL prefill. If you’ve ever looked closely at a link a company sent you, you might notice a format similar to this: https://www.tfaforms.com/4992347?tfa_1=yourname&tfa_3=youremail&tfa_5=customer In real life it’s usually a little harder to parse, but the idea is that you have a link to the web address, then after a backslash is the number or identifier of the particular form (4992347), then a question mark that tells your web browser what follows gets put onto the page that’s going to load. After the question mark you can see that question 1 and question 3 are filled with your name and email and question 5 has an identifier that you are a “customer.” This is basically a mail merge, only instead of creating a form letter, we’re creating a web form with some of the questions (possibly hidden) already filled out. As I said, most form tools can do this. Go ahead and follow that link–it’s a real form that doesn’t collect any information. If you modify the values in the URL, the answers in the form change. There’s nothing happening outside the form though. Try replacing “customer” in the URL with “reader” and see what happens. Honestly, URL prefill is pretty handy. You can send personalized surveys to people using your email marketing tool (like Mailchimp or Constant Contact), or from a spreadsheet, or out of your CRM. All you need to do is concatenate fields about the people into the right place(s) within the URL. This allows you to do some great things to make forms personal or to conditionally display the right questions, etc. But URL prefill requires that any logic (about the form recipient or related information) already be figured out before the form link goes out the door. There’s nothing dynamic about the information available to the form once that URL is generated. If I send you the link today and you wait a week to click on it, the form isn’t going to be any different. If I send you a link to a First Time Volunteer Experience form and then you don’t click on it for a month, having volunteered with my organization three times in the meantime, you’re still going to get the questions as though it were your first time when you finally click on that email. The Prefill Connector Unlike URL Prefill, FormAssembly’s Prefill Connector talks with Salesforce at the moment the form is loaded. This means that the form could look you up in our CRM by name and email and then, if it sees that you have already volunteered three times, show you a different set of questions than if you had just volunteered for your first time. Or we could take an example that doesn’t need any URL prefill at all. We could make a form on our website that’s for signup to our upcoming volunteer events. Most form tools would require that someone manually update the form as volunteer events are added to the calendar. But with the prefill connector, when the form loads it can ask Salesforce which volunteer events are coming up and then display those when it loads. Now if you want to add a new event to the signup form all you have to do is create that event in Salesforce. The next time someone goes to your website they’ll immediately have the new event as an option. Pause for a moment to think about how powerful that is. The prefill connector opens up all sorts of really interesting possibilities. Here a few to get you thinking: An attendance form: Teacher enters their email address. Form looks up the class for that teacher and finds all students in today’s session. All the teacher has to do now is mark each student present or absent. Now you don’t have to have attendance taken only by someone with a Salesforce login. A smart field trip form: Parent enters their email address and upon submit is redirected to a second form (for them it just looks like a new page.) Form looks up the kid associated with that parent and prefills the emergency contact information we have on file. Parent then fills out the field trip permission and can either change the emergency contact or keep what we already have, without having to reenter the information. A data update form: I click on a link that has my contact Id embedded in it. The form looks up my most up-to-date email, phone, and address, allowing me to edit or confirm that information. Of course, you could do this via URL prefill, but consider a couple of differences: WIth URL prefill the link would have to have all my personal information in the URL itself, so if I send that link out via email (which is always insecure), my personal information is pinging around the Internet unencrypted. Using Prefill Connector, when the form loads my information it communicates with Salesforce and my browser using secured HTTPS. WIth URL prefill, if any of my contact information changes in the database after the URL was generated, the form won’t know that. If I use the link a second time it will look like the changes from the first time never happened. With Prefill Connector the form is always up-to-date. A smart grades entry form: Parents arrive at the form with the unique identifier for their child (like from a mail-merged email reminding them to enter the child’s report card.) The form looks up which school the student goes to and their grade. Based on school and grade, the form asks only for the courses and grading method that is appropriate for that student. In theory you could do this via URL prefill too. But each parent’s link has to include all the information about the student, the school, and the report card type. That can be a lot to jam into that URL. And you would have to make sure you’re re-generating that URL any time a student’s information changes. Much easier to manage using the Prefill Connector. Realtime Information Display: This is just a single example of many ways you could create a form to display information to your stakeholders without needing to create a full-blown portal. Mentor clicks a link within the learning management system that has their contact Id embedded through URL prefill. Form looks up all the timesheets they have submitted, displaying the amount of time and whether that timesheet is approved or paid yet. Note: For a form like this, we hide the submit button. Now we’re just using “a webform” to pull data from Salesforce and display it. I’m not sure “webform” is even the right thing to call it anymore! Other Competitors It’s been a couple of years since I last spent the time to compare if other webform vendors have anything like FormAssembly’s Prefill Connector. When I last looked into it, the answer was a resounding No, though it took wading through a lot of marketing-speak to confirm it. Most salespeople hear a question about prefill and think you’re asking about URL Prefill, so they say “Yes, we have that!” But they don’t. Submit Connectors I don’t want to ignore the fact that FormAssembly’s connectors for putting the data into Salesforce once the user clicks Submit are also really powerful. (And maybe the subject of a future blog post.) But I think most form tool integrations have similar capabilities here, so it’s not my focus today. Anyone building webforms should keep in mind that you don’t necessarily have to put all the information you collect on a single form into a single object/table within your CRM. I could send out a single “post program form” for people to fill out that combines two different things, such as a post-module reflection (questions about the last module of the course) and course satisfaction questions on the same page. For the user, that’s one form. But when the data goes into Salesforce I can have the module reflection questions update one record while the satisfaction questions create a different record, perhaps even on a different object. Learning Curve Learning to use any webform tool is going to be its own learning journey. If you’re new to Salesforce and are about to integrate a webform–even one you’ve been working with for years–give yourself the time to explore and the grace to make mistakes. You can always ask for help from those of us a few steps ahead of you–we were in your place not too long ago!

Salesforce has come out with several features recently with “dynamic” in their names, including Dynamic Forms and Dynamic Actions. It’s clear the “dynamic feature” bandwagon is where a lot of future development effort is directed. But I’ll admit: I haven’t used them. I’ve followed the development of Dynamic Forms, but for the moment I’m still sticking with the “Related Record Hack.” And Dynamic Actions looks interesting, but I just haven’t taken the time to delve into it because I haven’t had a compelling need. Mostly, I’ve looked at those Lightning page advancements and thought, “they’re adding so many layers of [possible] complexity. How can admins ever find the time to sort through it all?” But Dynamic Gauge Charts actually caught my eye because they solve a problem I’ve run up against in my work. (Classic WIIFM. “What’s In It For Me?”) The problem they solve is that often you want to put a component on your dashboard that compares a report (such as a count of something) to a target number that isn’t itself derived from that report. The perfect example would be a chart of progress toward your fundraising goal. It’s simple to make a report of this year’s closed won opportunities, total up their Amount fields, and see how much you’ve raised. But if you want to compare that to your budgeted goal you have to put that goal into the dashboard gauge component manually. If the goal changes, you have to edit the dashboard to edit the component to change the breakpoints and target on the gauge. On the first day of the fiscal year, when the report underlying the dashboard rolls itself over (Close Date = “This Year”), the dashboard is suddenly way off because it’s comparing the total raised this fiscal year with the target left over from last fiscal year! Dynamic Gauge Charts allow you to make a gauge where you set the top end and breakpoints based on the value of a field on a particular record. Pretty cool! Now you can have a record for “Current Fundraising Goal” and point the gauge at that so that it stays current as long as that record is current. Set yourself a reminder to switch the number in the Current Fundraising Goal record on the first day of the fiscal year and all gauges on all dashboards are suddenly looking at the right new goal. Which brings us to keeping those target records current. Some target records are inherently manual, like the “Current Fundraising Goal” example. That’s a number that the executive leadership picks sometime before the end of the fiscal year and it’s not going to shift based on other records in Salesforce. It could be updated if circumstances change, but that’s a decision made by people. But I frequently get clients that want an organizational metric along the lines of 75% of all students will maintain a GPA of 3.5 or better, 100% of alumni will have full-time employment, or 90% of 8th graders will apply to competitive High Schools. Those percentages are derived from an equation. In the first example, the equation is: Count of students with GPA > 3.5 ____________________________ Count of Enrolled Students The number of students, alumni, or 8th graders—the denominator, in that equation—changes. It might change on any given day (if kids are accepted or removed from the program.) The numerator of the equation takes care of itself: You get it by running a report—and reports are always up-to-date the moment they’re run. But we have to update the denominator whenever kids come or go. On a dashboard without dynamic gauge charts we would have to edit the gauge target and breakpoints every time a student leaves the program! (Or at least every time we are going to refresh the dashboard to show executives how we are doing against our organizational goals.) So much for having the dashboard at your fingertips to impress execs. And let’s not forget that the three examples I listed all have different denominators! It’s entirely reasonable for a single program to have organizational targets like those–and probably a lot more. That could become a lot of target records to maintain. In fact, my client The Academy Group asked me to help them put together a dashboard with exactly that kind of organizational metrics. They work with kids from 4th grade through graduation from college. So they had metrics about the % of elementary school kids, % of middle school, high school, college, plus some specific to 12th graders, etc... It became clear very quickly that there are going to be a lot of different denominators required. I knew that just creating each of those metrics was going to be a bit of a pain in the neck: Step 1. Create report counting students in the category. (8th graders with GPA > 3.5.) Step 2. Put that report onto the dashboard as a gauge component. Step 3. Run a different report to figure out the denominator. (How many 8th graders are there?) Step 4. Edit the gauge target and breakpoints. Rinse and repeat. Manually updating each of those metrics even once a year would be no fun. And I know that sometimes students are removed from the program mid year and that Academy Group’s leadership is going to want to see the percentages based on the right denominator as soon as those kids leave. It occurred to me that this might be the time to try out those Dynamic Gauge Charts. And that’s when I realized that there aren’t any records in Academy Group’s Salesforce that could serve as the targets! We have a report of, for example, enrolled students by grade, but no record for those counts. It’s not even something you could make a DLRS rollup for. (There’s no parent/child relationship.) You could make some kind of Flow to get each of those counts, but you’d basically be making a custom flow for each target denominator. That’s not sustainable! Introducing DynamicGaugeTargets I figured it was time to sit down and build a thing. I knew it could be a thing that was reusable for some of my other clients. And then I realized I could release it as an unmanaged package so other organizations could also use it.. So I give you DynamicGaugeTargets, a completely free, unmanaged package that gives you the ability to keep those denominators up to date automagically. The package includes a custom object (called DashboardTarget) for storing all of your dynamic gauge chart target numbers. You can have dashboardtargets that you manually update when needed. But if you want auto-updated targets all you need is a little bit of [easily Googled] SOQL know-how and flows will keep you up-to-date. Do Try This At Home I would love to hear your feedback! Please try DynamicGuageTargets in your sandbox or dev org. Try out my installation and post-install instructions and let me know what you think. If you find this useful, go ahead and install it in your production instance and impress your colleagues with your dynamic dynamic gauge components. 🤯 If you find an issue or a problem, the GitHub Issues tab would be a great place to log that for me. For questions or comments, please post on the Trailblazer community or in Ohana Slack so that perhaps others can join the discussion. Or, of course, you can email me directly. I particularly want to hear your successes!

Salesforce is serious. 😒 It’s where we do our work. 📤 But, I don’t think there is an actual requirement that work be boring. Why not take the opportunity to make the system we work in a little more fun? Add joy (😊), affirmations (👍) and celebrations (🎉) anywhere you can! Adding emoji is nearly as easy as typing a character. On a Mac you bring up the emoji keyboard (⌨️) with Ctrl-Command-Space. On PCs it's Windows-Period. And emoji are text as far as computers are concerned--they're part of the unicode standard--so they work just about anywhere you can use text. Maybe it’s just decoration, but sometimes you get those proverbial "thousand words" by using a picture. That can mean pages that are more functional. Studies have shown that readers process visual information much more quickly than plain text. Besides, many emoji bring color as well as shape, so they brighten up your screen instantly! 🌈 Let’s look at some of the great places you can use emoji: 🗣 In Chatter (Of course.) We’re hardly breaking any new ground here, since it’s similar to putting them in your texts. 📇 Record names Now we’re having some fun! Could you put a stack of bills (💵) into your opportunity naming convention? [OK, that might not be serious enough.] Are you an animal shelter with records for cats (🐈), dogs 🐕, and rabbits 🐇? Put the type right into the record name and your users will instantly know something about Muffin! 📘 Description fields Any free text field is fair game! ⎶ As picklist values Setting a record’s progress to a Red🔴/Yellow⚠️/✅Green status field? Why not include the color in your picklist? Or perhaps you have radio buttons on a quick form–particularly useful on mobile. Instead of a Yes/No or a Good/Poor binary, why not 👍/👎? Instantly recognizable! 🎛 Dashboard or report names I hadn’t really thought of this before I started this blog post. But I’m definitely going to start renaming some more dashboards. No more “Organizational Goals Dashboards.” They’re all going to be “🎯 Goals Dashboard” from now on! ⍯ In formula fields On Related Lists I’ve written elsewhere about making a custom formula to combine fields for display on a related list. Emoji here can make your list pop, allowing users to instantly distinguish different types of records in the list. Visual Flags on Records We often want image badges on records and even the NPSP docs from years ago recommended a way to use static resources and formula fields. But for several years now I’ve preferred to make my image flags with emoji. Instantly readable on a record page and truly a lifesaver when you’re looking at a large report! 🏳️‍🌈 In banners I already posted about banners on Lightning record pages and you can see that I use emoji there. There are all sorts of possibilities when it comes to banners on your pages! 🖥 Flow screen instruction headers and sections Screen flows are a versatile tool (though sometimes quite time-consuming to build!) for building a custom interface in various parts of Salesforce. Whether the flow is a survey or call script, a custom New button in a specialized area, or just a way to display dynamically generated information in one place, I love to dress those screens up with emoji. When you put instructions on the page, start them off with a nice emoji to draw the eye. Differentiate sections with other emoji. 🛑 Error messages and validation rules Nothing says, “Stop!” better than a ⚠️ or a ⛔️, does it? Dress up your validation rules with a visual warning. (Or soften the blow with a smile. 😉) ⚡️ Lightning pages (like Home page rich text elements) Emoji can be welcoming additions to an instruction section or draw the eye to actions you can take on the page. I know that lots of people just zip right past the home page as soon as they log into Salesforce. But if you put some effort into it you can make Lightning App Pages functional and save your users time by allowing them to work right from the instant they log in. 🔘 Action buttons This is probably my favorite! Why settle for boring buttons like New and Edit? If you’re going to the trouble of making an action or a button, add some pizazz! I’m hardly the first to think of using emoji in Salesforce. Marc Baizman wrote a blog post back in early 2018. But I still l don’t think it’s as common as it should be. 🙁 One final note: Emoji and screen readers don’t always play nicely together. Generally the screen reader is going to read out the emoji's alt text, which you can see by hovering your mouse over one on the emoji keyboard. Keep your user base in mind and make sure the meaning of the icon is clear in context so that even when rendered as voice it doesn't get in the way. I've also seen advice to lead with text, putting the emoji at the end. (Good advice, though I didn't quite follow it to the letter for this post.) And don't forget to keep contrast in mind for the visually impaired. Now get to work, friends, and make those Salesforce pages colorful and fun! 🎈🎊

If you read my last post you were probably hoping that the title of this one would be My First Einstein Prediction. I was hoping so too. Sorry. But we're learning together! Here's what I've learned so far: Sandbox - What's the Point? First, I wanted to test in a sandbox because that's doing things right. But sandboxes, of course, have no data in them. I spent a chunk of time building out a moderate amount of fake data so that the models would at least let me turn them on. Even the time I spent just resulted in a whole bunch of very boring donations (all the same amount, on people named Contact 1, Contact 2, etc...) I could have spent dozens of hours learning Snowfakery to insert interesting data. But who has the time? And anyway, even with interesting fake data, how interesting are predictions about it, really? So working in the sandbox got me proof that it's safe and possible to install, enable, and activate the Einstein Prediction Builder (EPB) models that Salesforce.org has provided. But if I wanted to really learn anything about the models I was going to have to run them against real data. New Org - No Magic Bullet I first turned on Einstein Prediction Builder (EPB) in the org for my client The Modern Classrooms Project. (Really interesting organization, by the way, and great fun to work with! Super smart staff that are excited to try new technology and have quickly learned how to build in Salesforce and FormAssembly.) MCP doesn’t have a ton of donation data because they’ve only been on Salesforce for about two years. Plus most of their income is from earned revenue. I was interested to turn on EPB in their org first to see how the NPSP backup prediction models would work when I knew there wouldn't be enough of MCP’s own data to run the machine learning. Well…I wasn’t too impressed. Here are the results: First Time Donor - This one’s kinda’ interesting, if not particularly helpful. As I understand it, the model assumes that if someone has good contact information and the contact record has been created in the last three years, they’re likely to become a donor. Modern Classrooms is a new Salesforce instance (so all records are created less than 3 years ago.) And we are building out program management on the platform, so we’ve imported well over 6,000 program participants. They all have good contact info. (It would be hard to work with them if you couldn't contact them…) I suspected Einstein was going to say everyone has a good likelihood of becoming a first time donor. And I was right. The scorecard says “Prediction quality is too good to be true.” Even Einstein is skeptical of its prediction that basically every mentee and mentor in Salesforce is likely to become a donor to Modern Classrooms. Top Donor and Recurring Donor just straight up failed due to too little data. Sigh. Tons of Data - No Luck Yet Next I turned to the Clean Air Council, a client that has lots of data in their org, both many years of data from within Salesforce and decades of older imported data. I thought for sure I’d learn something from that experience! Here I’ve been stymied even worse. It’s been more than three weeks since I installed the predictions and turned on the models. Everything’s still stuck in Pending status. I even opened a case with Salesforce support. All they’ve been able to do so far is point me toward a Known Issue that has no known workaround. I Guess I'll Get Back to You I'm still committed to taking Einstein Prediction Builder out for a spin. Keep your fingers crossed that my next post is actually titled My First Einstein Prediction...

At Dreamforce last month I was excited to once again hear people from Salesforce.org (SFDO or “.org”) mention Einstein, Salesforce’s name for their machine learning offerings, and how they might be used by nonprofits. You see, several years ago, when Einstein was first announced, I tried to pin down Salesforce.org executives to find out if/when Einstein would be available to nonprofits, how we might use it, and what kind of discount we could expect when pricing was announced. I got exactly nowhere back then. List pricing for Einstein wasn’t released yet and nobody at .org would commit to what kind of discount they would offer nonprofits in percentage terms. (Not my first or last tilt at transparent pricing.) In the intervening couple of years Einstein has been front and center of messaging but I will say I have barely heard a word outside of Salesforce’s own marketing about people actually using it. And to add the confusion “Einstein” is now applied to several different products, such as Einstein Bots, Einstein Activity Capture, and more. You’ll sometimes hear people (including me) joking that Salesforce is just going to prepend “Einstein” to the name of any product they want to imply is “smart,” whatever that might mean. The Einstein product that I’ve been keeping an eye on from the beginning is currently called Einstein Prediction Builder. This is the one that most closely matches what I think of when I consider how machine learning or “AI” could be applied for nonprofits. It’s the tool that should allow me to one day, for example, to look at potential matches of mentors with mentees and find those that are more likely to produce good outcomes. Or perhaps I could point Einstein Prediction Builder at a set of students and their program engagement data and determine who among them is in danger of dropping out of the program? So imagine how interested I was in the Nonprofit roadmap session to hear that Salesforce.org has actually put some effort into making it easier for nonprofits to use Einstein Prediction Builder. That’s potentially really cool! If we can figure out what it means. And I’m not trying to knock SFDO here–I actually think their materials were about as clear and transparent as a high-profile product announcement was ever likely to be. But Einstein is complicated, Salesforce licensing is complicated, and what Salesforce.org built is a little challenging to sum up in just a couple of sentences. So let’s start with some gratitude: Kudos to SFDO for trying to get Einstein Prediction Builder into the hands of nonprofits! There’s potential there for some interesting wins. The Announcement: Einstein for Nonprofits (I don’t actually think that Einstein for Nonprofits was a new announcement at Dreamforce, but it was a nice high-profile reminder that this is something SFDO is counting among its big releases for 2022.) Let’s break down the dense language of the linked help page to understand what this is. It’s really two things: 1. It’s Einstein Prediction Builder (EPB) That’s not really a special product for nonprofits. Any org can turn on EPB in “Try Einstein” mode and build a couple of predictions and even activate one of them for free. So this is a bit of repackaging of Salesforce platform capabilities to let nonprofits understand that we get them as well. 2. It’s also some additional sweetening by Salesforce.org a. First of all, Salesforce.org has built three prediction models for us. That’s actually pretty cool, as building prediction models is the difficult and confusing part of using EPB. In this case, SFDO has created predictions for whether a contact in your system is likely to become a first time donor, is likely to become a top donor, or is likely to become a recurring donor. These predictions are all based on the NPSP donation rollup fields. So as long as you’re using NPSP and its customizable rollups in more-or-less the way they were designed, these predictions should work for you out of the box. Neat! Another benefit of these predictions is that they serve as examples of a 100% nonprofit-specific use case and exactly how you would implement it. I’ve done the Einstein modules on Trailhead and come away with a vague sense of what I might try to build for a nonprofit but there was a good deal of fuzziness there. Seeing an actual prediction and then actually using it against real data is the kind of learnin’ I need. b. SFDO has also created “backup models” for those orgs that don’t have enough data. One of the limiting factors of Einstein (or any machine learning) is that you have to feed it a whole lot of example data so that it can analyze and look for patterns. An Einstein prediction won’t even run if you have fewer than 400 example records and can point to a good chunk of both positive and negative outcomes. If you’re an organization that’s new to Salesforce or doesn’t have hundreds of donations imported from an old system you wouldn’t be able to build an EPB prediction at all. But SFDO has worked to gather a big dataset and build the models you’ll need so that you don’t have to start from scratch and you can use EPB before you have enough of your own data to train it on. c. An Einstein for Nonprofits app that can make it easier for you to find the EPB settings, the backup models that SFDO provided, and links to resources. d. There are also some Lightning Web Component cards that you can put on a contact page to display the results of the Einstein predictions. [Can I be honest and say that I don’t think these cards are really worth much? Sorry–I’m callin’ it like it is. We could replicate this display in five minutes with the Related Record Hack and we’d have better control of what we are displaying.] The Price You’re probably wondering what Einstein for Nonprofits costs. [At least, you’re probably wondering this if you’re cynical, like me, and assume that we can’t be getting anything worthwhile for free in this world.] I’ve got good news on that front: Einstein for Nonprofits is free. Everything I listed in the section above is totally free to nonprofits. One active predication is actually free for any org in the first place on the Try Einstein level of EPB (more on this below), so there’s no free platform feature being handed out here. But SFDO is throwing in those pre-built predictions and the backup models to train them, as well as those pretty-but-inconsequential contact cards. That’s actually a pretty nice deal, I think. And if you want to upgrade from the Try Einstein level that only allows one active prediction, you can get an Einstein Predictions license for $225/year, a 75% discount from the regular price. An Einstein Predictions license is a feature add-on to one of your existing user login licenses. You need that feature license only for the person that is going to create and manage your Einstein Predictions. Everyone else will be able to see the results. With an Einstein Predictions license you can also activate up to 10 predictions (and build up to 20.) Should I use this thing? If you’ve been paying attention, I bet you have one more important question about Einstein Prediction Builder and Einstein for Nonprofits: Should I use it? (And, if yes, how?) Well I’m still working on investigating that with the help of some of my clients that have a good amount of data in their orgs. I’m going to make that the subject of another post as soon as I can. Tentative title: My First Einstein Prediction.

It’s time to wrap up this series on what to do when you’ve found yourself with system administrator privileges and are trying to figure out next steps with a little discussion about certifications. For people actively trying to break into Salesforce as a career, getting a certification is often an early step. But if you’ve fallen into your Salesforce journey and have a spot at a nonprofit that you’re enjoying, there’s really no reason to race toward certification, in my opinion. But it’s a good idea to have certs on your radar and start thinking about studying for the main gatekeeper cert: Administrator. Here’s the dirty little secret, though: The Admin Cert focuses a large percentage on features and concepts that you just aren’t going to use that much in the nonprofit context. So if you’ve had admin permissions for a while and have started doing more and more work on Salesforce in its own right in the context of your nonprofit position, you’ll find that the material on the admin cert might not seem directly relevant. Doesn’t mean you shouldn’t learn it and that you won’t find it helpful, but it isn’t going to reflect your day-to-day. If you’ve learned to manage users, create custom fields, and work with reports (all things you can learn on Trailhead) you know more than enough to answer the admin cert questions on these topics and you probably even have some practice that helps solidify that knowledge. What you probably don’t know about are things like who sees what and governor limits. That being said, I think you should consider Admin your first certification goal because it’s the one that most people know, understand, and–perhaps most importantly–respect. Salesforce Certified Administrator is a difficult exam. First of all, the material is technical and most of it will be new ground you haven’t really covered. Also the questions (or, really, the answers) are structured differently than multiple-choice tests you’ve taken in the past. A lot of them ask for which 2 or 3 answers are correct, rather than you having to find only the one plausible answer among those given. I failed the admin cert exam the first time I took it. (As have many others.) I strongly recommend having a basis of good, hands-on experience built up over months or years, plus some focused studying. (I used Focus on Force and Salesforce Ben for some courses and practice exams.) Amplify also has study groups that are a terrific resource. That first exam is going to be a challenge, but it will give you a foundation to really feel like you know your stuff and are ready for deeper Salesforce involvement. In the process of earning the Certified Administrator credential you’re going to learn things about the platform that will inform the work you’re doing. You’ll know more about why reports and dashboards work how they do, what design/architecture choices have been made for your current system, and what you can and can’t easily do to make changes to your instance. There are probably two other certs that have caught your eye on that link above: Platform App Builder - I think of App Builder very similar to the admin cert, though it’s definitely less difficult. App Builder is also an entry-level exam, but it doesn’t serve as a prerequisite for other exams like Admin does. Take Admin first, then I bet you can pass App builder with little additional study–it’ll be material you’ve got well in hand. The content of App Builder is more focused on (Surprise!) building apps on Salesforce and less on the technical underpinnings of the platform itself, such as privacy/visibility and governor limits. I’m sure there are lots of people that would recommend this as a first certification and I can’t really argue with them. I just think if you’re already working with Salesforce and are going to take the time to study for a first cert, I vote Admin. While putting App Builder on a resúmé might help you get a job, I haven’t seen too many job posting that ask for an App Builder certification. Nonprofit Cloud Consultant (or Education Cloud Consultant) - Naturally, if you’re coming to Salesforce from a nonprofit/education perspective, these make some degree of sense. But these are consultant-focused exams, rather than user/admin focused. Questions focus on considerations around building a new implementation, for example, rather than the kinds of work you do to support and modify an existing instance. There is a lot of common sense to figuring out the answers (though you also need to know features and terms of NPSP and EDA), but the real benefit of having one of these is going to come if you’re looking for a consulting job. There’s nothing wrong with getting one (or both) of these certifications, but I don’t think they’re going to be as helpful in doing your current job as Admin or App Builder will be. You can do this! First Installment: Get on Trailhead Part Two: Engage in the Community

Want to know a superpower that you can get without being bitten by a radioactive spider, is available to you right now, and can help you whether you’re a beginner or an expert? The Salesforce community is a superpower for everyone. Whether you need the answer to a flow question, want to find your next job, or just want to nerd out about building and designing on the platform, you’ll find someone, somewhere, to connect with. What really makes the Salesforce community special is that the culture incorporates paying it forward, generosity with time and wisdom, and always ensuring that there is no such thing as a stupid question. Let me tell a story of when I got started in Salesforce. It was 2013 (which seems like a long time ago) and I was brand new to “this Salesforce thing.” I had started to play with a trial org because I thought Salesforce might be a good fit for the organization I was working for and I had some questions. Because I was working for a nonprofit, I found the Power of Us Hub, which was the Salesforce community specifically for nonprofits and educational organizations. I asked a few questions about how to customize things and got answers that were always respectful of my newbie status and helpful and affirming. People like Judi Sohn were happy to help me with basic setup UI questions and to confirm for me that I was on the right track as I built or modified fields, layouts, and formulas. I knew I was asking basic questions and I was delighted with this helpful online forum. It was not lost on me that this was a helpful and welcoming part of the Internet. Then I started asking some more focused questions about the address-tracking functionality in the Nonprofit Success Pack (NPSP), which was a little hard to truly grasp. (Still is.) After some back-and-forth, eventually Beth Saunders asked if we should just jump on the phone to play around and try to figure things out. Beth was a stranger to me at the time but she was willing to take a chunk of time out of her day to just figure things out with me. That was my introduction to the Salesforce community and the beginning of a friendship and a turning point that would lead to a new career. But as generous as it was of Beth to offer to get on the phone, I have come to learn that what she did was not out of the ordinary for this community. Even consultants billing by the hour are happy to give time and attention to help out newcomers. It’s just in the DNA of the Salesforce online community that we are welcoming and that we share our knowledge so that others may grow. We lift each other up. The culture is such that our first instinct is to be welcoming and so the circle is virtuous. My second recommendation for new admins, therefore, is to get involved in the Salesforce community online. (First recommendation was Trailhead, last post.) If you’re reading this blog you probably have discovered the community. But I know that plenty of clients I work with, and admins, and users of Salesforce have not yet dipped their toes into the wider Salesforce community. Log into the Trailblazer Community (it’s now a tab of Trailhead) and join a couple of groups. Find people that are discussing topics of interest to you. Ask questions when you have them, or lurk to just soak things up. The Nonprofit Hub is the new home of the Power of Us Hub. (There’s also an Education Hub.) And there are groups for job seekers, for marketers, by industry, etc. You can find a group to learn about Flow, groups by region, and more. Just join a bunch–you can always pare down the list later. There is also a Salesforce community on Twitter and one or more on Slack, of course. As I understand it, all share the great culture of the Trailblazer Community. That was the easy part because you can do it from your couch. But did you know that the Salesforce community is so passionate about learning and networking that there are entire conferences focused on Salesforce that are organized by volunteers? There are more and more Dreamin events every year. Some are larger, some are smaller, Some are one day, others two or more. These are a fantastic introduction to the community. First of all, you’ll get the opportunity to meet in person the people you’ve seen online. But it’s also a place to learn skills, network, and have fun. Conferences offer content for users and admins at all levels. I just got back from Midwest Dreamin, the OG of these community events and–I think–still the largest. What a great time! I learned so much about the Salesforce platform, reconnected with friends and colleagues, and met new friends and future colleagues. I know that some of you are reading this and thinking, “I’m an introvert, conferences aren’t for me.” I would argue that you are wrong about that. I am definitely an introvert. (I’m not shy, for sure, but I am drained by being with people. And a room full of strangers and "cocktail party conversation" makes me want to crawl out of my skin.) It energizes me, however, when I can get a chance to go deep into conversation learning or discussing something of mutual interest. Well guess what? A conference brings together dozens or hundreds of people that share an interest in common! And this is a conference of the Salesforce community, so our online community norms of welcome just transfer right over. You will find Your People even if you are an introvert. (And, I think, even if you are a little bit shy.) Community conferences like Dreamins are not free, though they keep the cost low. And many offer discounts for nonprofit employees. Dreamins are an amazing value for the amount of learnin’ you get in a day or two. And because local conferences are less expensive than something huge like Dreamforce you got a good turnout of nonprofiteers to network with. I actually did not get my start at Dreamin events, though. My introduction to Salesforce events came through a special creature called an Open Source Sprint. These are hosted by Salesforce.org and are focused directly on the nonprofit Salesforce sector. (And, in my opinion, they’re perfect events for introverts.) We come together for two days to work on projects together. (What better activity for introverts than to work together toward a common purpose?) If you’re a nonprofit Accidental Admin, attending a sprint is one of the best ways to build your network, grow (whether in Salesforce knowledge, writing, project management, or other useful job skills), and to have some fun. Sprints are free, though the full experience comes from traveling to the in-person sprints (which are starting back up this fall.) Sprints move around the country in an effort to reduce the cost and burden on nonprofit employees trying to attend. Watch for one near you! So you got your admin permissions and have become an Accidental Admin. Well why not turn yourself into an #AwesomeAdmin–a true superhero that can help your organization thrive with Salesforce? Launch yourself into the Salesforce community online and through in-person events and you’ll earn your cape in no time! Last time: Trailhead Next time: Certifications