The Context – Imagine an org with…
- 100% clicks no code
- 200+ users
- High service volume
To add to this, the org wants to expand the use of cases within communities and have the ability to communicate asynchronously within the case context bidirectionally with the customer.
So far so good, right? But…
The Challenge
A) Visually the conversations should be threaded and not as separate comment entries.
B) Should be a clear Call To Action within the same actions list that the service users use today.
From customer experience and user interface, the above is argued to be the best approach here. Now, whilst most of the things are there out of the box in communities (phew!) the above two are not.
1 – Thread pickle
So you have the “Community” quick action that you can add to your layout, yet that will not keep the conversation on the same thread, but will instead look something like this:
Instead they are looking for something like:
2 – Feed Action Pickle
That out of the box “Community” quick action is adding a case comment record to that case and marking it as public. So a completely different object than the FeedItem which can potentially keep things threaded.
Whilst you can scroll down and use the box that displays “Write a comment”…
…this does not display in the same workspace as all the other actions service users can do to communicate with customers like send another email, which would keep the UI and user behaviour consistent.
So what are we going to do?
The Recipe
- 2 freshly baked custom fields
- 1 quick action, roughly chopped
- a handful of goodies on a flow
- 1 process to bind the sauce
The idea with this is to reuse as much of what already exist with Feed Items as possible, while keeping with the motto of 100% clicks, no code.
What we know is that what makes FeedItems have that thread is having in common a “ParentFeedItemID”, so a new feed item created to respond should share that same parent.
That explains the 2 fields, one to host in the case record the “ParentFeedItemID” & another one to hold the value of the text we want to send to the customer.
Having then the case record in question as our common item to refer to.
We add then the action to update the “CaseFeedItemBody” field within the case record.
Doing this now we have the event that will trigger everything else. Starting with a process builder when a case is updated only when the “CaseFeedItemBody” field is changed.
Although let’s build first the flow which will convert the information we have into that threaded conversation.
What we need in the flow is to look if that ParentFeedID is already populated – if not we create a new one and update the value on the case record. Otherwise we create a FeedItem with the existing parent.
You will be creating a few variables that we will use to pass information from the case around, all of type text and for ease with type ‘input and output’:
- varCaseID (variable to host the case record ID)
- varFeedItemBody (variable for the message the service user want to send to customer)
- varParentFeedItemID (variable to get the threads going)
- varFeedItemID (ID of the newly created FeedItem)
Always remember as best practice when using create and update elements to restrict them only to the record ID, in this case only create/update when the case ID is as varCaseID.
Once it is activated we get to build the process builder to bind everything together, parsing the data into the variables we need for our flow:
Tada!
It may sound to some (and to be fair I surprise myself sometimes) a little bit like Donald Duck in Mathmagic Land 👇
*Especially minute 4*
…but in a sense I suppose this reminds us that there is always more than one way to achieve the same outcome 🙂