On March 1, 2020, the official start of Spring ’20 in our world, comes needed security improvements regarding sharing data with external users. However, you can uncheck the Secure guest user record access checkbox and test out these changes until Summer ’20. Phew. If you’re using any Site Guest Users, and are ready to try out the new settings you’ll need to create new sharing rules. Hint: Salesforce sites are used in Volunteers for Salesforce and frequently in Communities.
What’s a Salesforce Site? “Salesforce sites enables you to create public websites and applications that are directly integrated with your Salesforce.com organization—without requiring users to log in with a username and password. You can publicly expose any information stored in your organization through pages that match the look and feel of your company’s brand. Use sites to create public community sites to gather customer feedback, branded login and registration pages for your portals, Web forms for capturing leads, and so on.” — the Site setup page in Salesforce. Continue reading →
“I am trying to set up an autolaunched flow to remove Opportunity Contact Roles from open opportunities with deceased contacts. (For example, we are soliciting a major gift from a couple, and one of them passes away before the donation is received.) I have successfully configured a process to remove the deceased contact from acknowledgement for that gift when it comes in, but for the sake of clean data I would like to also automatically remove their OCR from the opportunity record. I am coming up with ‘unhandled faults’ and hoping since this is only my 2nd flow ever that someone will be able to see an obvious error with my configuration.
Dude. With the Spring ’20 release, we can now update 1000s of records at a time in Flow. The release itself doesn’t give us this power directly, but it allows developers to create invocable apex actions that can be reused for many objects.
That’s me living my dream while the audience listens on headphones.
Learning how to build a Flow is like interacting with a volunteer who…needs some extra help. Through these videos, I explain some of the trickier flow concepts for admins: “get records” and “record variables.” I was lucky enough to give his presentation at Dreamforce 2019.
Good news: in this version I have unlimited time so I’ve shown all the steps in detail.
More good news: this presentation doesn’t actually utilize anything specific to nonprofits so it’s suitable for you Sales Cloud folks as well.
Wednesday, 12pm Westin St. Francis with Salesforce.org staff Jessie Rymph
Flow is a powerful automation tool that walks users through screens, updates multiple objects at once, and reaches distantly related records all with clicks-not-code. By learning Flow, nonprofits can surpass the limitations of Process Builder and harness the power of code without actually having a developer on staff. In this session, we’ll demystify record variables, “get records”, and other elements that are often unfamiliar to non-coders. Participants will walk away with an understanding of the *why* behind each step in the flow creation process!
Thursday, 11:30am Moscone West with MVP Maya Peterson
One process to rule them all, one process to find them, one process to bring them all and in the invocation bind them. As a best practice Salesforce now recommends restricting your org to one record-change process per object. Truly a tool of great power. In this session you’ll learn tricks to manage process criteria nodes using Custom Metadata Types, Custom Settings, and Custom Permissions. No harrowing trip to Mount Doom required.
Almost 4 years ago, I started a new job as the company’s Salesforce Admin. When I joined, they were on their 5th year with Salesforce. I soon learned that inheriting a Salesforce instance has its benefits…and its challenges.
I often found myself wondering, “If we could start over and implement a new instance of Salesforce, what would we do differently?” I’d note down observations I had when things went well and especially when they didn’t. Over time, my list grew (and was repeatedly validated).
The goal behind the below recommendations is to make life easier as an Admin. While some recommendations may take more time to execute, in the long run, it will make your job and the job of anyone joining your team a whole lot easier.
Focus on data quality. Decide early on the information you require in order for a Lead, Account, Contact, Opportunity to be created. With Leads and Contacts, I cannot stress enough the importance of a complete company name and contact name with either phone number or email and state or country. Company websites are super helpful, but you can create a custom formula field to extrapolate this info from the email address.
On the topic of data quality, have a data management strategy to moderate and maintain clean data over time. For example, we had a report on reports not run in the last 6 months. We’d notify users that we are deleting reports and remind them to run the report if they didn’t want it deleted.
Use that Description field. Every time you create a custom field, report, dashboard, workflow rule, etc., make sure you fill out the Description. My recommendation is to include why it was created (especially if it was requested by a specific person or team, include that). This information is super helpful down the road when trying to figure out why you have this or that and what you need to keep or can delete.
When creating custom fields, be careful about the field type. Multi select picklists are difficult to report on. With picklists, select the option to “restrict the options to picklist values” and if you do offer an “other” option, create a dependent text field to capture that info. Also, if you plan to use in-line editing in list views, be aware that certain field types aren’t supported (long text area, rich text, checkbox, etc).
Turn on Field History Tracking. You can select certain fields to track on each object. Best practice is to track ownership fields, fields important for compliance, and anything that impacts a business decision, such as who owns this record. The field history is shown in the object’s Field History related list.
Have minimal page layouts. When you add a new field or a new app, you have to then add it to the proper section on each page layout, which can be very time consuming. Multiple profiles can share the same page layout, and you can control visibility on a profile by profile level. If you want to hide a field, make it no longer visible in in the Field-Level Security.
Utilize Record Types. If you have different business processes for a Lead/Account/Opportunity, than consider having different record types for each object. You can set up unique picklist values, sales processes and page layouts for each record type. If you have a sales team going after Enterprise accounts and another going after SBM, consider leveraging record types.
Create a custom field to indicate what type of deal the Opportunity represents. Is it New Business versus an Upsell versus a Renewal, etc.? I have often leveraged this field when creating validation rules, workflows, process builders, etc. Also consider automating the naming of new Opportunities. We chose to standardize Opportunity names in this format: Country – Company – Record Type – Opportunity Type – Year.
Thank you for taking the time to read my post. This list wasn’t intended to be exhaustive as these are recommendations based on my specific observations over the past couple years. There are many excellent posts of Salesforce best practices, and I encourage you to check those out too.
Allow Recipients to Unsubscribe From All Email Sent via Salesforce
When the recipient clicks to unsubscribe, a flow will look for all contacts and leads who have this as their preferred email address (if you’re in Nonprofit Success Pack) or in the Email field. All contacts or leads who meet that requirement will be marked “Email Opt Out.” The email address owner will receive one confirmation email immediately.
Oh man…so much good stuff in the new release. And a real bummer.
Add a lookup component in Flow
I’m really disappointed about this. I was confusing “lookup” with “search.” I want to search for any record I want and get a list returned. Nope. I can search using any lookup field I already have. This is good, but not quite what I was thinking.
RIP Bailey Bones, my beloved companion of 14 years.
Unsatisfying use case : A dog turned in at the animal shelter has a microchip number (text field) which I want to use to search for potentially matching dogs. I want to look up a dog in my flow then process their intake at the shelter.
Possible solution: I could do this if I had the microchip number in the name of animal, like Bailey 238392, and I looked it up to the animal record from say, an adoption record. It has to already be a lookup field.
Satisfying use case: Let’s say I am processing an animal record for adoption. From the animal’s record, I can lookup the Contact record of the person who is adopting the animal as part of my animal adoption flow.
Note: you can do a work around for this kind of search. Thanks Jenwlee.