Logging future timeline activities

@sarahmiracle Couple of discussions we’ve had:

• What happens if the customer cancels or doesn’t show up?  Assume you’d either have to create a field to record that or delete the activity.
• Unless the meeting is also on their calendar, it doesn’t really show up anywhere like a future CTA/Task would.

We’ve actually already implemented a system 😅 and we have a single select picklist on the activity for Activity Status, for Scheduled/Completed/No Show/Canceled….but users not being able to edit each others’ timeline activities makes it very tricky...

@sarahmiracle Because several folks on my CS team were measured on frequency of certain types of touches, I’ve put the word out to my users not to use Timeline for entries in the future. Though I could have managed around parts of it, future entries just got overly messy, and sometimes misleading if folks were not watching the dates closely. To your point, future entries are often speculative due to meeting reschedules, cancellations, etc.. It especially became a problem when folks starting using future Timeline to essentially “pin” items to the top, where they would store links to SFDC, our apps, Asana, Google Drive, or other apps.

Basically, to drive the documentation behavior we wanted to incent across the team, we essentially said, “No future entries”. My compromise position was if they really wanted to start up notes or prepare an agenda before a meeting, they could do so as a DRAFT entry.

I’m not sure why one would want to use TImeline for this purpose when this is exactly a use case for CTA.  Timeline is a “point-in-time” entry.  To capture notes and information around what happened not what is going to happen.

Also both @matthew_lind and @heather_hansen’s points, what if the planned event doesn’t occur? Also what if the person who created the entry leaves or switches roles?  Timeline entries are fixed records and non-owners cannot go back and change them.

CTA’s, on the other hand, are perfect for scheduling actions/activities that will occur in the future (in fact, there’s even a Recurring feature - that should be used cautiously of course).

My 2 penny recommendation: use the right feature for the right use case rather than attempting to force something to do what it wasn’t designed to do.