Under review

Notifier: Push the message out when story goes live

Jason Braverman 5 days ago in BLOX Total CMS • updated by Christine Masters (Director of Product Management) 2 days ago 6

Say a reporter is completing his/her story. They've added the photos, gallery and any other assets. Next they move over to "Notifier" and create a tweet and FB message and hit "Save and Send." By default, since the story isn't "live" on the website yet, it goes into "draft" mode. Next, they'll promote the story for the editor to read. He/she reads it and promotes it to the web. Shouldn't the tweet and FB post go live at that time? 


I wondered about this as well. I scheduled a Facebook and Tweet for a story that was to publish at 7 p.m. It still had to go through our copy desk, but the notifier message stayed in draft after publication.


OMG, this!  The notifier  app is overall a big improvement, but this drives me nuts.  Our standard workflow was to have stories written, tagged, and socializ-ed before editing, with the do not publish flag checked.  Way more efficient than what we have to do now because the notifier defaults to draft.

Under review

Are you sure they aren't hitting "save as draft"? "Save as draft" will do what you say (saving it as a draft until it is published - even if the story goes live). "Save and send" will send it as soon as possible, which would be when the story goes live.

I will do some testing of this to confirm the above behavior... if it is not doing that I would agree it is a bug.

Are you guys using workflows? Does the start time of the asset pass before the the publish setting is enabled?

They are hitting "Save and Send." 

We are using workflows. The start time has passed before the publish setting is enabled most of the time - mainly due to the normal flow of the day in the newsroom. 

Jason, we're going to treat this as a bug for now... Can you submit a CRM ticket with an example of an asset that didn't get posted, if you have one? I would like to see the domain set up and so forth.

As a side note, we do have a setting now to "reset start time" as part of a workflow change. So, when the article goes live, you can reset the start time to now, and this may actually fix the issue (we'll need to test that), but it may be desired behavior on your side anyway, regardless of whether or not it fixes the issue.

That way, the article start time reflects the actual time it went online, rather then when the reported started working on it.