function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
earlbarbyearlbarby 

Fully overriding Answer Customer standard publisher with custom email publisher in Case Feed

Hi,

We're attempting to make a custom email publisher for Case Feed to completely replace the standard Answer Customer publisher and we're running into severe obstacles. We must be missing something with at least some of the below issues because this is seeming very developer unfriendly. Any help is greatly appreciated.

1) The VF page added to the Feed must have a static height and apex:emailPublisher widget has elements that dynamically expand/shrink on clicks. This creates whitespace under the publisher inside the page's iframe and creates an obvious gap above the actual feed. That is, unless we use javascript to automatically control or lock element sizing. Scrollbars inside of the iframe are worse. Are there any other options here?

2) In Summer 13, if you remove the standard Answer Customer publisher from the Feed then the Reply and Reply All buttons on email feed items simply don't work. In Winter 14 under the same setup, those buttons now pull the user out of the feed and send them to the native Send Email page. Ideally, since we're trying to replace the standard publisher, we'd like those buttons to take users to our custom publisher within the feed. Another acceptable option would be for the buttons to simply be removed from the email feed items when the standard publisher isn't on the feed layout. Given this behavior with the Reply buttons, how can we possibly make it so users will default to our publisher? They'd have to consistently remember to ignore the easily accessible buttons on the emails themselves and instead always choose the proper action from the left bar.

3) If we select a custom button from the "Replace Send Email Button with" menu and use the standard Answer Publisher action then we are presented with a stripped down email publisher, which sends an email, and then redirects per the button. What is the purpose of this if the email is always sent through the standard publisher anyway regardless of the override?

Thanks.

earlbarbyearlbarby

I forgot one:

4) If we have the standard email publisher configured with Action Fields then those fields show up on our custom publisher when showAdditionalFields=true. This is a nice, click-saving feature because it allows an email to be sent while simultaneously updating case fields. However, if we remove the standard publisher then the Action Fields section also disappears from our publisher. Can this be prevented?

Scott BeechukScott Beechuk

Hi earlbarby,

 

Thanks for the feedback on Case Feed, great to hear from you.

 

1. You are correct, the VF custom publisher actions are fixed height today. We have plans to introduce a javascript API that will allow them to be dynamically sized in a future release (safe harbor applies).

 

2.  You are also correct here, we enhanced the Reply buttons' functionality to make sure they function even without the email publisher. Your use case is different and I will note it. Sorry there isn't an easy workaround today.

 

3.  The replace email button is more of an "onsuccess" hook, which allows you to run additional transactions in addition to sending the email. It wasn't intended to have access to the payload of the email body or other fields of the publisher, nor was it designed to reroute the email through a different send path. Sorry if that wasn't clear in the documentation. Again, will note your request here, although depending what you actually want the button to do, the best option still may be a custom action.

 

4.  It sounds like you want a hybrid visualforce-declarative publisher where your custom publisher would have a footer section that contains declaratively defined fields. We did not design for that use case, although I think I understand where you're going with that. The best way to implement that today would be to simply add those fields in your VF publisher page code. You could achieve the same functionality, although the layout of the fields would only be modifyable in the VF code.

 

Would you mind sharing your specific use case that is steering you in the direction of a custom email publisher? We may have something on the roadmap to help.

 

Thanks,

Scott

haydzhaydz
Hi Scott,

I also ran into a use case for a custom email publisher if you're interested. In a nutshell - we need to be able to bulk send using the publisher using the functions it already provides (email editing, email templates, attaching/inserting knowledge articles). 

"It wasn't intended to have access to the payload of the email body or other fields of the publisher, nor was it designed to reroute the email through a different send path"

More specifically, we have a VF page that allows you to bulk "Close" child Cases belonging to a parent Case, and then an email that gets sent to all Contacts associated to the Cases.

Having access to the payload is a minimum I needed to get this done, as I could then construct the mass email using that. The customer requirements were specifically to be able to select a template, edit the email, and add knowledge articles (everything the email publisher already does). 

Thanks,
Hayden
Ido Greenbaum 10Ido Greenbaum 10
Hi Scott, 

Regarding number 2 - can you share any status on the 'Reply' and 'Reply All' not working when overriding the Default Email Publisher? 

Thank you, 
Ido. 
Ido Greenbaum 10Ido Greenbaum 10
I was able to overcome this obstacle, and fire the appropriate Email Template on 'Reply' and 'Reply All', implementing 'QuickActionDefaultsHandler'.