Filtering in Lightning's Activity Timeline
- Author
- David Reed
- Published
- Words
- 774
The Lightning Experience's record pages come with a very nice Activity timeline and publisher.
One of the features of this timeline is highlighting different types of activities with topical icons, and permitting the user to apply filters on the fly to isolate activities of interest - like just Emails, or just Calls, or all Tasks owned by the user.
How, though, does Lightning distinguish between these different activities to populate the various filters? And further, can we control that filtration to place activities we generate under specific filter headings?
The answers turn out to be "a bit of magic" and "sort of." Lightning recognizes five categories of activity: Emails, Events, List Emails, Logged Calls, and Tasks.
Events are distinguished from Emails, List Emails, Logged Calls, and Tasks by sObject type. Events have the object type Event, while the other four are all of type Task. The Emails, List Emails, Logged Calls, and Tasks filters work differently. All of them filter based upon the picklist value in the field TaskSubtype on the Task object.
Confusingly, this field isn't connected to the Type field whatsoever - it's not a dependent field, and the Type field plays no role in Activity filtering.
This field is populated by the system, and cannot be changed. At the database level, it's createable but not updateable.
[
TaskSubtype] Provides standard subtypes to facilitate creating and searching for specific task subtypes. This field isn’t updateable.
The four values of this picklist (which is restricted) are Email, ListEmail, Call, and Task, each of which maps to exactly one filter. Email and ListEmail are entirely separate; they don't appear in one another's filtered view.
Manipulating the TaskSubtype
Knowing, then, how Lightning sorts tasks under different filter headings, can we manipulate the filters to sort our custom activities in bespoke ways? Only to a slight extent, as it turns out.
We cannot change the behavior of the filters. The Activity timeline is a non-configurable Lightning component; we can add it to record pages, but it doesn't have any public attributes for us to set.
Because the TaskSubtype field is createable, but not updateable, we cannot move existing records from one category to another.
The one route we have is to override the category at the time of creation of the Task, and there are some unique behaviors to this approach. When inserting records via the publisher, if the TaskSubtype is ultimately going to be 'Task' (i.e., it is not an Email, List Email, or Call), we can, in a before insert trigger on Task, set the TaskSubtype to one of the other three values. A putative Task can be transmogrified into an Email, Call, or List Email:
However, this does not work in the other direction. Records that are being created from the publisher as Emails, List Emails, or Calls can't have their TaskSubtype overridden to 'Task', or to any of the other available values. Attempting to do so has no effect on the created Task, although it doesn't cause an error. The TaskSubtype field is null upon publisher creation; it's set behind the scenes at some point between the before and after trigger invocations, but by the time we reach after insert, the field's inherent non-updateability takes over.
None of this applies to Tasks inserted via Apex. If the publisher isn't the source of the Task, any TaskSubtype value can be transformed into any other.
There's still one more caveat of applying this technique, though: if the Task-to-be-converted is added via the publisher, Chatter records the original type of the task in its feed:
This mismatch does not occur when the Task is inserted via code, which doesn’t produce a Chatter post and hence preserves the illusion of being (say) a Call the entire time.
The question of whether it's wise to manipulate the Activity timeline in this way is another story. Because this functionality is at least somewhat undocumented, I wouldn't rely on the publisher continuing to work exactly the same way in future API versions. Vote for this Idea to make TaskSubtype editable!
One last interesting facet: there's similar data model on Event, with Event.EventSubtype. Like with Task, this field isn’t updateable. However, permitted values are not documented, and the picklist has only a single value, 'Event', which is populated on standard events. Perhaps we'll see more functionality around timeline filtering in future releases.