Skip to main content

Cleaning up reminder tasks

It seems fairly standard practice to create reminder tasks to nudge reps about neglected opportunities. We do that for open opps that haven't been modified for 30 days, and for renewal opps when they get within 90 days of the renewal date. Do your reps always take action? Yeah, mine don't either.

My concern is that these reminders become noise. The few new alerts get crowded out (attention-wise) by all the alerts that have been sitting around neglected. The net is that reps learn to ignore these alerts, and they become pointless. What to do?

One step I've taken is to automate cleanup of certain old tasks. This post and the next will walk through the steps I've taken. My aim is to (1) delete any 'Not Started' tasks associated with opportunities when the opportunities get closed, and (2) delete any duplicate reminder tasks on a given opportunity when creating a new such task.

To do this, I'm going to create a flow which, given an opportunity id, will delete a set of associated tasks. There are really two flavors of the flow. One flavor will take as input an opportunity id and will delete all tasks with status of Not Started (I'll subsequently refer to these more simply as Open Tasks) related to the same opportunity. The second is triggered when a new task is created, and it deletes only Open Tasks with the same subject which are related to the same opportunity and assigned to the same user.

Today's focus is creating the flow. After launching Flow Builder, I first switch to the Manager tab and create the variables I need. For each variable, I use the New Resource button, and create a total of five variables:
  • varOppId - this is a text variable, available for input, and represents the id of the opportunity
    Flow Builder variable resources
    whose tasks I'll consider deleting. This is the only input that I'll set when closing an opportunity; the other inputs (as well as this one) apply when creating a task
  • varOwnerId - this is a text variable, available for input; it's the id of the owner of the newly created task
  • varSubject - this is a text variable, available for input; it's the subject of the newly created task
  • varTaskId - this is a text variable, available for input; it's the id of the newly created task, with a default value of {!$GlobalConstant.EmptyString}. The default value is how I'll differentiate the two flow flavors
  • varTasks - this is a record variable, able to contain multiple values (that is, a collection)
Flow Builder - Tasks collection variable

With the variables defined, it's time to create the flow. The first step is to determine which flavor of the flow to run. That's determined by whether the input varTaskId is null, so I have a decision element. The two outcomes are HasTaskID (that is, varTaskId is not equal to {!$GlobalConstant.EmptyString} and NoTaskID (the default outcome).

Get Records - SOQL criteria
Each outcome leads to a GetRecords element, which is essentially a SOQL query built via clicks. For the 'HasTaskID' branch, I'm looking for Tasks that match the inputs varOppId and varOwnerId, whose id is NOT equal to varTaskId (that's the task just created; I want to create duplicates, not the new task itself!) and whose status is Not Started. I assign the resulting collection to varTasks and, if no results are returns, set varTasks to null.
**CAREFUL** You may want to be more specific with your SOQL criteria, perhaps requiring that the Subject is 'Reminder', the WhoId is blank, etc. If your criteria are fairly liberal, you may delete more than intended!

The SOQL query for the NoTaskID outcome is simpler; only the criteria for Status and WhatId apply. Here too, the results are assigned to the varTasks collection variable, which is set to null if no results are returned.

Both of these GetRecords elements flow next to a decision which simply tests whether varTasks is null. The outcome representing varTasks is NOT null leads to a Delete Records element. I delete records using the ids stored in the varTasks collection variable.

So that's the entire flow... Along with the five variables, I have two decisions, two 'gets' and one delete element. 

After some testing (the Debug feature of flow builder ROCKS), I saved and activated the flow. I named it DeleteUnstartedTasks (this comes up when it's time to invoke the flow from Process Builder), and its type is Autolaunched Flow. 

Next time we'll use Process Builder to launch this flow under the two circumstances - an opportunity being closed and an open, opportunity-related task being created.


Comments

Popular posts from this blog

Salesforce Pipeline Reporting - part 1 of 3

In a dozen (plus) years working with Salesforce, I've never been entirely happy with the built in reporting of my opportunity pipeline. I can export details, or a printed (formatted) view, but I lose the interactivity. I can use a dashboard, which is better now in Lightning in that I can see a lot more fields in a table component. But flexible views require filtered dashboards, and just maintaining the filter values (if they go down to a rep level) can be onerous. Plus applying (or removing) a filter tests my (very limited) patience. So I've typically exported the report details into Excel, and there created a workbook that includes (1) summary info, (2) scrollable deal lists with hyperlinks back to the opportunity records in Salesforce and (3) filters that let me instantly switch views, say among teams, reps, opportunity types, or fiscal periods. My process around this involved LOTS of VBA and LOTS of formulas. Lately, I've (finally) gotten turned on to slicers in Exc...

Using Excel with Salesforce: One tool, two tips

Obviously, Salesforce has strong built-in reporting tools. And I'm a big fan of the dashboards, especially filtered dashboards and dynamic dashboards. WAY better than the old approach of creating a unique set of reports and a corresponding dashboard for every conceivable view. Still, I often want to pull my Salesforce data into Excel. This might be for further manipulation / processing, aggregating data that doesn't live in Salesforce, or distribution to non-Salesforce users (hey, those licenses are expensive!). Reporting Tool - XL-Connector: I'm using a new (to me) tool when I have to repeatedly pull Salesforce data into Excel: XL-Connector  (fka Enabler 4 Excel) from Xappex. There's a lot you can do with XL-Connector. My primary use is just to extract data from Salesforce, and this can be done in two ways: reports or SOQL queries. The great part is that once you've captured data into an Excel file, refreshing the data is trivial. I've stored my credential...

Salesforce reporting: XL-Connector and VBA

In an earlier post , I mentioned a tool I'm using to import Salesforce data - via SOQL or existing reports - into Excel. This post is more about using that tool, XL-Connector from Xappex . Here, I'll walk through the (simple) process of importing and refreshing a report, and I'll provide a simple VBA macro to automate the refresh. In a future post, I'll expand on that macro to show a friendly view of my opportunity pipeline and a single-page view of how each of my sales reps are doing against a series of KPIs. Importing a report is simple enough. From the XL-Connector tab, select Log In and enter your credentials. I'm using the old id and password (as opposed to SSO), so I provide that along with my 'token'.  (Don't remember your token? Log in to Salesforce via your browser, click on your photo, select Settings, then 'reset my security token'.) Once you're logged in the lock turns green. Back in Excel, on the XL-Connector tab, select ...