Our org is going through a re-architecture - and large updates are causing row locks because many records are being related to a single parent record. While I can find descriptions of cause of the issue - which I understand - I don't see any guidelines on the optimal batch size to use when performing updates where the likelihood of row lock is very high. (all updates referencing a single parent). Is there a standard practice to reduce the number of records that end up in the asynchronous queue? Running batches at 500 records, serial is working fairly well - but I don't know if there is a specific limit of batch size that could be used to prevent row locks entirely.

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.