Author: Stephanie Damgaard

  • Learn Native Salesforce Duplicate Management at Virtual Trailblazer Community Event

    Learn Native Salesforce Duplicate Management at Virtual Trailblazer Community Event

    Join the Baltimore, MD Administrators on March 25 at 1pm EDT

    Lane Four’s own Andrew Sinclair will present on all things duplicate management at this upcoming event. Here’s what you need to know.

    About the Session

    A Deep Dive into Native Salesforce Duplicate Management

     The session will explore advanced concepts of duplicate management and discuss how matching rules can be extended using custom Apex, flows, and clicks.
     
     After the session, attendees will have a good understanding of the following topics:
     
     • How to configure custom duplicate management
     • What types of things can be matched
     • The difference between alerting, reporting, and more
     • How to use matching rules in code with Match Methods
     • How to use the reporting data to run merges both manually and in code
     • How this native functionality can replace third party tools
     

    About the Speaker

    Andrew Sinclair, Founder & Salesforce Consultant, Lane Four[br]

    Andrew Sinclair is a Salesforce architect with a reputation for helping high-growth startups scale Salesforce across their businesses. He is the founder and owner of Lane Four, a boutique Salesforce consulting firm based in Toronto. He has also been the architect of multiple AppExchange applications, including Lane Four’s account-based lead management app, which launched in 2017.

    Register for this VIRTUAL Session Now!

    FEATURED RESOURCE

    Salesforce for
    SaaS Blueprint

  • Using Workflow Rules & Process Builder in Salesforce

    Using Workflow Rules & Process Builder in Salesforce

    We recently kicked off our new series on choosing the right Salesforce automation. Today, we’re taking a deeper dive into the first two options for real-time automation in Salesforce: workflow rules and process builder.

    Using Workflow Rules

    Workflow rules should be the first type of real-time automation you consider—with one major caveat. Salesforce has indicated that they will not be adding any new functionality or upgrades to workflow rules. Given this, we generally recommend avoiding workflow rules in favor of process builder unless you already have workflow rules on your object, do not already have process builders on your object, and meet the following use cases for workflow rules:

    • When working with edition limitations (for example, Professional Edition only allows maximum 5 processes; 1 per object)

    • For simple field updates on the same object (but without dynamic picklist values or IDs being set)

    • Email alerts

    • Task logging

    • Outbound messages (via an integration and only when necessary)

    If you don’t meet these conditions for using workflow rules, move on to consider process builder.

    When Should I Use Process Builder in Salesforce?

    • When using a field reference for a picklist field update or when setting a lookup field. These are the primary limitations of a workflow rule.
    • When you need to reference information from parent records. Use this in your update function.
    • When you need to create additional records. For example, custom history tracking.
    • To mass update child records. For example, changing the opportunity owner when the account owner changes. (Keep in mind the limitations below.)
    • To launch a flow. The only alternative way to launch a flow is through Apex or a button that a user must click on.
    • To declaratively instate a platform event. Which you can write Apex to subscribe to—ultimately replacing the need for an Apex trigger.
    • To declaratively call an Apex class. Also removing the need for an Apex trigger—for example, when invoking a third-party tool like DLRS.

    Need a Salesforce
    Expert?

    What Do I Need to Know When Using Process Builder?

    If you select process builder for one of the use cases above, you’ll need to watch out for a few things. With features like process builder, Salesforce puts powerful, no code dev tools in the hands of admins. If used improperly, these tools can cause dramatic damage to your Salesforce instance. So if you’re an admin, think like a developer and heed the warnings below.

    You should only have one process builder per Salesforce object.

    This means that you might have many actions built into a single process builder—and that’s the right approach. (One exception to this rule is when you have one process builder for creation events and one for update events.)

    Be very careful about the order of actions in your process builder.

    Because you will probably have multiple actions in a single process builder, you need to pay attention to the order in which things happen. If you don’t, one of two issues can result: some automations may never be hit, or multiple automations may be hit in succession.

    As an example of the latter, let’s say your process builder is set to assign the lead when the status is MQL and assign the lead when the next call date equals today. If your marketing automation system sets both values simultaneously, a record may be assigned twice because it will hit both steps of the process builder.

    To avoid this, make sure that you sequence your automation so it will hit the steps exactly as expected.

    Make sure you handle empty values.

    Be mindful of when a filter value or update value may be empty and build the possibility of an empty value into your logic. Often, this simply means adding an extra filter to your process builder to accommodate for an empty value.

    For example, if you’re running an automation on a contact and you only want it to fire when the contact status equals qualified and the contact’s account status equals prospect, your automation will catastrophically fail if the account value is empty. To prevent this, you would add “contact’s account is not null” to your logic.

    Understand maximum data volumes.

    Because process builders can be CPU intensive and sensitive to high data volume, errors like 101 SOQL errors or CPU timeout can occur. This can happen if your process builder is invoked during large data processing events like data loads. This also applies to when process builder mass updates child records. For example, if you attempt to chage contact owner based on account owner you’ll run into issues if you have 500 contacts at an account.

    Avoid the 2 most common admin errors.

    The two biggest mistakes people make are enabling recursion when they don’t understand what it means and failing to ensure that the process builder is running only on desired change events and not all updates. Recursion fires the process builder multiple times can cause CPU errors — more stuff’s happening.

    What issues have you run into with workflows and process builder? We’d love to hear from you!

    Next up in the series, we’ll be discussing flows. Follow us on Twitter or LinkedIn for the latest.

  • February 2020’s Awesome Reads for Sales Leaders

    February 2020’s Awesome Reads for Sales Leaders

    Intent data. Dynamic guided selling. Outbound strategy. Account selection. We’ve rounded up some of February’s best sales content for your perusal. Check it out below!

    First Steps With Intent Data? Start With Sales | Demand Gen Report

    The popularity of intent tools has spiked over the past year. But how do you get started with implementing these tools, and who should be responsible? Bombora’s Mike Burton makes a case for starting with sales.  Read more.

    Getting Started with Outbound Sales? (Let’s Start with Strategy) | Sales Hacker

    For those kicking off or improving their outbound programs, Sales Hacker offers a no-nonsense breakdown of the key elements you need to build a successful strategy. Read more.

    Account Selection: How To Win Before You Start | TOPO

    Good account selection is vital to every account-based strategy. Check out TOPO’s advice on how to do it right, including how many accounts to choose, how to choose them, how to allocate resources, and other best practices. Read more.

    Supercharging Sales with Dynamic Guided Selling | Forrester

    Sirius Decisions and Forrester provide a glimpse into the future of sales technology. Read more.

     

    FEATURED RESOURCE

    Sales Process
    Template

  • How to Handle Community Guest User Access Issues Before Salesforce’s Summer ’20 Release

    How to Handle Community Guest User Access Issues Before Salesforce’s Summer ’20 Release

    Salesforce’s Summer ’20 release introduces changes that will severely impact Communities with guest user access. These updates—going live in the coming weeks, exact date to be announced—will cause major failures to your customer-facing Communities if you don’t take preventative measures.

    Here’s what you need to know to protect your Communities from breaking.

    Will it impact me?

    In Salesforce’s words, new Community settings will “enforce private org-wide defaults for guest users and restrict the sharing mechanisms that you can use to grant record access to guest users.” They will also remove “various obsolete user permissions from guest user profiles to enhance data security.”

    Practically, this means that new rules will impact any active, public facing Salesforce Community that allows guest users to create, edit, or query records. Ensure that you review all of your Community settings in depth to determine if these changes will affect you. Salesforce recommends running the Guest User Access Report to review how guest users in your public Communities can currently access objects.

    What will go wrong?

    This update will cause your Community to break if guest users attempt to create, edit, or query records.

    How can I protect my Salesforce Community?

    To protect your Community, we recommend reading the resources at the bottom of this page in full, and consulting an expert if you are unsure of anything. Here is a summary of basic steps you should take to protect your Salesforce Community.

    1. Define a guest site user who will own records.
    2. Create a sharing rule on all all relevant objects the guest site user is required to access.
    3. Update classes that do edits on behalf of the guest site user to use without sharing notation. This includes any class called by the guest site user that does a query and edit operation.
    4. Assign apex classes to the guest site user profile.

    Further Resources

    To adequately protect your system prior to the updates, we recommend reading the following resources:

  • How to Choose the Right Real-Time and Code-Based Automation in Salesforce

    How to Choose the Right Real-Time and Code-Based Automation in Salesforce

    Our team of admins deploys hundreds of Salesforce automations every year. Given this, we’ve experienced a huge breadth of automation use cases, with a range of outcomes along the way. Recently we decided to pool this knowledge to create a comprehensive guide to Salesforce automation best practices.

    Over the next few months, we’ll be sharing our insights in a series of posts that will explore when to choose each type of Salesforce automation, along with major considerations and things we’ve learned the hard way. The considerations that follow will be fairly technical and specific but, taken in a larger context, will comprise a helpful guide to Salesforce automation for admins.

    Choosing Your Real-Time or Code-Based Automation

    Let’s kick off by looking at how to choose the right real-time and code-based automation in Salesforce. When choosing your automation, there is a logical hierarchy of options to consider. Below, we’ll explore these options in the order in which you should consider using them.

    1. Workflow Rules

    The first type of automation to consider is workflow rules. Workflow rules are viable for the following use cases:

    • When working with edition limitations (for example, Professional Edition only allows maximum 5 processes; 1 per object)
    • For simple field updates on the same object (but without dynamic picklist values or IDs being set)
    • Email alerts
    • Task logging
    • Outbound messages (via an integration and only when necessary)

    If non of the above use cases apply, look at process builder next.

    2. Process Builder

    Choose process builder for the following use cases:

    • When using a field reference for a picklist field update, or when setting a lookup field. These are the primary limitations of a workflow rule.
    • When you need to reference information from parent records. Use this in your update function.
    • When you need to create additional records. For example, custom history tracking.
    • To mass update child records. For example, changing the opportunity owner when the account owner changes. (Keep in mind the limitations below.)
    • To launch a flow. The only alternative way to launch a flow is through Apex or a button that a user must click on.
    • To declaratively instate a platform event. Which you can write Apex to subscribe to—ultimately replacing the need for an Apex trigger.
    • To declaratively call an Apex class. Also removing the need for an Apex trigger—for example, when invoking a third-party tool like DLRS.
    * Note: Process builder can not perform queries or nested/complicated decision logic. If you need to perform a query to decide what to do, you must use a flow.
     
     

    3. Flow

    Flows can perform a lot of functions that process builders cannot. Select flows for the following use cases:
     
    • When you need to do a query
    • When you need to create records and reference the results in a subsequent update
    • To do a screen flow — screen for user to interact with
    • To launch an action from a button
    • When you need to create multiple or dependent objects/records  (for example, when you need to create a record from the account, like clicking a button to create an opportunity and/or product)
    • To delete records

    Learn more about flows.

    4. Apex Trigger

    • When working with high data volume. Triggers can perform faster in such situations: if you’re getting process builder errors due to volume, consider using a trigger.
    • To control order of execution. If you have something in code and something in process builder and you need them to run in a specific order, use a trigger.
    • When everything else is in code already. When you’re forced to build out a complex coded process, it’s a best practice to consolidate your automations in code. Don’t create a rogue process builder here, because your developer won’t know what it’s doing.
    • If you need to fire before insert or on delete. (Note: this will change in a future release, which will have flows firing before inserts.)
    • When you have really complicated criteria, because apex triggers can execute this much faster. It is possible to cripple your system with a CPU timeout error if you have a process builder dealing with too many operators (for example, we’ve seen this happen with too many “title contains” operators).

    Learn more about Apex triggers.

    Need a Salesforce
    Expert?

  • Awesome Reads for Sales Leaders [January 2020 Edition]

    Awesome Reads for Sales Leaders [January 2020 Edition]

    We’ve rounded up some of the best sales content published this January. Take some time to peruse insights on everything from must-attend sales events to sales ops best practices.

    Why Sales Dev Stack Innovation Is Getting Smarter While Budgets Get Tighter | TOPO

    TOPO’s recent research cuts through the tech stack noise to reveal which tools are actually working for sales, and where we’re headed in 2020. Naturally, we’re thrilled (but not surprised) to see that lead-to-account matching tools score among the highest for both impact and satisfaction. Read more.

    8 Sales Operations Do’s and Don’ts | Outreach

    Whether you’re just kicking off your sales operations or you want to improve, this list provides solid best practices for the role.  Read more.

    Improve Your Pipeline: Let Sales Control the Flow of MQLs | Sales Hacker

    This article introduces an unusual approach to managing leads: letting sales leadership control the MQL threshold.  This is an interesting take on how to better align marketing and sales in the midst of some common challenges. Read more.

    2020 Must-Attend B2B Events | Demand Gen Report +

    The 10 Best Sales Conferences to Attend in 2020 | Brainshark

    Mark your calendars! These lists of must-attend events in 2020 are a great place to start if you want to keep up with the latest trends in sales technology, strategy, and tactics. Read more here and here.

    The Five Lessons B2B Sales Leaders Should Learn to Make Analytics Work | McKinsey

    How can B2B sales leaders empower their sales force with analytics to achieve growth? McKinsey lays out some practical strategies for getting started.  Read more.

    Did you miss any of Lane Four’s sales resources this January? Check out the highlights:

     

    FEATURED RESOURCE

    Sales Process
    Template

  • Salesforce for Non-Profits: The Basics

    Salesforce for Non-Profits: The Basics

    Last week, Lane Four founder Andrew Sinclair spoke to fundraising students at Toronto’s Humber College on the fundamentals of Salesforce for non-profits. In addition to sharing examples of Lane Four’s extensive work with non-profits, Andrew reviewed the benefits of choosing Salesforce, and the fundamentals of going live.

    The Case for Using Salesforce as a Non-Profit

    Salesforce’s commitment to give 1% of its product back to the community (as part of their 1-1-1 philanthropic model) makes this software affordable to many non-profits. Not only do non-profits receive their first 10 Salesforce licenses for free, but Salesforce also offers a significant discount for additional licenses. It’s worth noting that, even at a reduced cost, non-profits access the same powerful technology that major companies are using around the world.

    Salesforce is becoming an increasingly popular choice for non-profits, with fundraising management as a core use case. Unlike many of the finance-focused systems that non-profits have traditionally used, Salesforce is centered on people. This makes it ideal for organizations managing people-centered activities like fundraising, sponsorship, and program delivery. Salesforce also facilitates basic marketing and communications activities (like emails and other correspondence) that are difficult or impossible for finance-focused databases to do.

    Getting Started with Salesforce for Non-Profits

    Andrew recommends that most organizations kick off Salesforce with contact management. At this stage, it’s important to begin by looking at who your people are, and how you want to refer to them in your system. Terms and taxonomy can be a barrier to tool adoption, so it’s important to name your objects and fields properly at the very beginning.

    When it comes to naming your Salesforce objects, for example, the sales-oriented label “Accounts” may not accurately describe the groups you work with. Instead, you may want to use a term like “supporters” if you deal with donors and sponsors,  “households,”  if you deal primarily with individual family members, or a more generic term like “stakeholders” or  “organizations” of you work with a broader range of groups.

    Andrew recommends starting this process by creating an information tree. This will allow you to visualize and account for all of the constituents you work with. What stakeholder information do you need to track and take action on? Where do stakeholders’ identities overlap (for example, are some donors also volunteers)? This information will inform your taxonomy and how you will structure your data.

    Fundraising and Program Management Use Cases

    Once your non-profit organization has kicked off contact management in Salesforce, you can start thinking about additional processes to roll out. Andrew typically asks organizations to consider which of their time-consuming manual process might be most easily automated in Salesforce.  Andrew often starts fundraising teams off with simple but impactful processes like automating tax receipt generation.

    Lane Four has also design several more advanced non-profit use cases in Salesforce. Many of Lane Four’s long-term non-profit clients have worked their way up incrementally from contact management to complex, custom program management.

    As an example of this approach, Andrew shared Lane Four’s work customizing Salesforce for the Academy of Canadian Cinema and Television. Over the past 6 years, the Academy’s Salesforce instance has evolved from a simple member database into a complex system that handles corporate sponsorships, donations, and membership renewals, as well as submissions and voting for their annual awards.

    Andrew highly recommends taking an iterative approach, building your Salesforce processes over time, for successful implementation and adoption. This approach is particularly useful in resource-limited organizations like non-profits.

    __

    Ultimately, Salesforce is a viable option for a wide range of non-profits. We recommend that non-profits consider Salesforce for its affordability, powerful tech, and high level of flexibility and customization.

    FEATURED RESOURCE

    Salesforce for
    SaaS Blueprint

  • Setting Up Your Salesforce Integration in Outreach? Use These 5 Best Practices.

    Setting Up Your Salesforce Integration in Outreach? Use These 5 Best Practices.

    Integration with Salesforce can be the key to making sales engagement platforms like Outreach successful. Since spearheading Lane Four’s work as an Outreach Implementation Partner, consultant Joana Lourenço has learned a ton about what makes this core integration work.

    “There are a few things that people tend to skip when first setting up their integration,” says Joana, “but doing a couple of extra steps can make a huge difference in how Outreach will function as an extension of your overall data strategy.”

    Luckily, Joana has agreed to let us in on some the secrets she’s learned after nearly 100 implementations. Do these five things when setting up your Salesforce integration in Outreach, and you’ll thank yourself later.

    Pay Attention to API Limits

    When you’ve connected the Salesforce plugin in Outreach, one of the first things you should do is check your API limit. Hitting an API limit in Salesforce is a huge headache—and it’s becoming more and more common as the tech stack grows. Hitting this limit in Salesforce with one tool will cause all of your other integrations to fail. For example, if you hit this limit in Outreach, your marketing automation system integration will stop working too.

    To avoid this, set a threshold for API calls that’s lower than your overall API limit. This will prevent Outreach from syncing any more data once the lower threshold has been reached, but before you’ve gone over the actual limit. Outreach’s Salesforce plugin will show you your maximum API limit;  Joana recommends setting the threshold to about 70% of this API limit.

    Beware that your initial Outreach sync may use up the a lot API calls (1 API call per record created). So, if you’re syncing 10,000 or more records initially, you may hit your API limit right away. Make sure you set a lower API call threshold before your initial sync, and you’ll avoid headaches on this front.

    Learn More: Understanding API Call Usage

    Set Up Your Custom Fields

    If you need any of your custom Salesforce fields to be visible in Outreach, you’ll need to complete this two-step process:

    1. Create a custom field in Outreach and give it a label
    2. Use the Salesforce plugin to map your custom fields to each other

    If you don’t map your custom fields before the initial data sync, it might take some time before you see this field information in Outreach. Individual record updates in Salesforce trigger record updates in Outreach. So if you don’t set up custom fields off the bat, none of the data from your custom fields will be synced until a change has been made to each individual record in Salesforce. This can be an issue if your reps are relying on information from custom fields.

    All of the workarounds for this issue after your initial data sync are time-consuming, and require using a ton of API calls in one go. Do yourself a favor and set up custom fields on prospects, accounts, and opportunities before you bring in any Salesforce data.

    Manage the Opt-Out Field

    Getting the opt-out process right has never been more important—especially in light of the privacy laws rolling out in 2020. Luckily, Outreach has built-in opt-out systems that can work great with some simple setup.

    In the Salesforce plugin, Outreach’s Opted Out field is mapped to the standard Salesforce field called Email Opt-Out. But some organizations aren’t using this Salesforce field; often it’s not added to the Lead or Contact page layouts. In order to capture and sync email opt-outs between Salesforce and Outreach, you’ll first need to make the Email Opt-Out field visible in Salesforce and add it to record layouts.

    It’s also worth noting that Outreach provides flexibility for opt-outs. Instead of a global opt-out, you can now set up separate opt-outs for email, phone, and SMS communications. If you want to take advantage of this feature, review your options in Outreach and make sure that all of your communication preference fields are syncing to Salesforce.

    Whatever route you choose, make sure that you’re reviewing your opt-out strategy as a whole. Not only with Outreach and Salesforce, but also with marketing automation systems and anywhere else you’re storing contact data.

    Learn More: Communication Preferences (Granular Opt-Out)

    Set the Right Conditions for Inbound Create

    When you first set up your integration, you may want to set conditions for which records to bring in from Salesforce. Before you go ahead and toggle the Inbound Create button to sync all of your data, pause to consider what you actually need to store in Outreach. As we all know, Salesforce can be rife with duplicates, outdated leads, and other information that’s useless to SDRs. Don’t waste API calls syncing unnecessary data.

    Joana often sees clients set an Inbound Create condition around the lead or contact status field. You may choose to only sync prospects that meet the right conditions for SDR outreach—for example, qualified prospects.

    Learn More: Salesforce Integration Toggles Explained

    Need a Salesforce
    Expert?


    Be Thoughtful About Your Outreach Stage Values

    The Outreach Stage field is important, and Joana recommends setting it up on day one. The majority of Joana’s clients map their Outreach Stage to the lead status in Salesforce. But unique lead statuses may not line up with the standard Outreach Stage values—for example, if your values are marketing-focused (like MQL, SQL, and SAL). In this case, you may want to create a custom field in Salesforce called Outreach Stage to capture this data.

    If you’re syncing contact data into Outreach, make sure that you create a field to capture your Outreach Stage on that Salesforce object too. Remember that lead status is a standard Salesforce field, but contact status is not, and the values may differ. So make sure you’re syncing data from Outreach accordingly.

    Bonus: Consider the Possibilities of Advanced Task Mapping

    Tools like Outreach greatly expand the possibilities of activity reporting in Salesforce because they automatically generate a ton of accurate activity data. If you want to generate sales engagement activity reports in Salesforce based on Outreach activity, enable advanced task mapping within Outreach. In order to turn on this functionality, you’ll need to contact Outreach support. Then, you’ll be able to map task data from Outreach into custom fields on Salesforce’s task object.

    Learn More: Advanced Task Mapping Overview

  • Activity Reporting for Account-Based Sales

    Activity Reporting for Account-Based Sales

    Activity reporting has long been the go-to method for measuring sales engagement activity in Salesforce. But until recently, it was almost impossible to generate accurate engagement metrics this way. Luckily, sales engagement platforms like Outreach have completely changed the game for activity reporting.

    Before, we had to rely on sales reps to manually enter tasks and events into Salesforce. Now, engagement metrics flow directly into Salesforce from platform integrations with zero effort from reps. Instead of patchy, self-reported numbers, we now have numbers in Salesforce that directly reflect rep activity.

    This new setup makes it possible to finally build activity reports that are reliable, meaningful, and actionable. But it’s critical to take a couple of extra steps to build relevant activity reports for an account-based landscape.

    Here are a few considerations that will help you get the best possible account-based activity reports from Salesforce.

    Understand How Account-Based Activity Reports Differ

    There are a few ways to look at engagement metrics via activity reporting. The simplest approach is to look at pure volume metrics. For example, the raw number of connects, calls, replies, and clicks occurring. Volume metrics are helpful for things like compensation and simple predictive conversion metrics, but they’re simplistic.

    Slightly more sophisticated, prospect-based activity reports break down task and event metrics by person. This allows you to look at activities on specific individuals, titles, or roles to determine who you’re engaging and whether they’re worthwhile. Prospect-based reports can also consider things like last engagement date and last relevant engagement date to determine relevance.

    Today, account-based activity reporting is by far the most important kind. Modern sales teams are tightly focused on account activity, so account level metrics are crucial. Common account-level metrics include coverage rate, demos booked on target accounts, demos completed on target accounts, target account conversions, qualified opportunities at target accounts, and conversions from demo. Remember that account-based metrics typically need to be time-bound in order to be useful (based on the date an account became a target).

    The best rule to follow when determining what kind of account-based engagement metrics you need is to ask yourself one key question. What actions are you trying to drive? If you correlate your metrics with your answer, you’ll be in good shape.

    Beware of Multiple Objects for Account-Based Engagement Reporting

    Account-based reporting depends entirely on information aggregated at the account level. This means that any information you’d normally be pulling from the lead object—as you would for prospect-based engagement reports—won’t be accessible. This is why so many companies are turning to lead-to-account matching solutions to bridge the gap. This is also why we advocate for a contact-only assignment model for sales, and reserving leads for inbound marketing prospects.

    Remember that any activity information you want to report on at the account level must be associated with the account object. In an account-based organization, it’s critical to use this fact as a guiding principle for your processes and data model.

    Avoid Salesforce Features that Impact Activity Logging

    Whether you’re generating engagement metrics at the volume, prospect, or account level, there are some Salesforce limitations to be aware of. In particular, two new features throw a wrench into activity reporting:

    Enhanced Email Feature. This feature aims to provide users with new email functionality, including the ability to “relate emails to other records, add custom fields to emails, use triggers with emails” and more. Unfortunately, it does not create tasks. Beware: this feature is automatically enabled for most Salesforce orgs, so you will need to disable it to prevent gaps in your reporting.

    Einstein Activity Capture. This feature syncs your calendar with Salesforce—automatically adding emails and events to the activity timeline of related Salesforce records. But it does not create tasks from these emails.

    If you intend to rely on task and event reporting, you may want to avoid these features. Alternatively, you can look to third party tools to record email activities as tasks.

    FEATURED RESOURCE

    Data Management for Account-Based Sales