A new year, a new decade (or not, depending on how pedantic you want to be.)
But for Coles, it seems the 1st of January is the perfect time to start selling hot cross buns in readiness for Easter. Hop to it and don’t leave it too late to buy them – Easter’s only three and half months away!
Here’s another weird issue in transitioning to the Lightning user interface in Salesforce.
One of our users who regularly adds Chatter posts to records in the system, reported that they were unable to post a new Chatter thread against a record. On checking I likewise found that on the Chatter tab there was a bold invitation to “Collaborate here! Here’s where you start talking with your colleagues about this record.” But there was no way to actually post a message!
The issue turned out to lie with the Global Publisher Layout, which defines the actions that will be available for Chatter. From Setup search for “publisher”, click on “Publisher Layouts” and then edit the “Global Publisher Layout”
The “Classic Publisher” section defines what chatter actions will be available in the classic interface, and if no overrides are made in the “Lightning Experience Actions” section, then the Lightning interface should inherit the settings from the “Classic” section. However I found that it wasn’t until I saved the layout (without even making any changes) that the Chatter actions appeared in Lightning.
After clicking on “Quick Save”, the “Post”, “Poll” and “Question” actions appeared in the Chatter tab in the Lightning experience.
This post documents an obscure issue I discovered relating to the Salesforce Streaming API after switching to the new Lightning user interface.
For several years now at work we’ve had an integration that uses the Salesforce Streaming API to sync customer and contact information from Salesforce to an on-premise system. Recently after some users transitioned to the new Lightning user interface, the integration stopped working.
On investigation, it turned out to be related to field permissions. One of the fields configured in the PushTopic was a formula field. The permissions on this formula field were set to make it readable by only Administrators and the Integration user.
When using the Salesforce classic interface, if another user (who did not have read permission on the formula field) updated a record, the formula field value appeared in the streaming event
When using the Lightning interface, if another user (who did not have read permission on the formula field) updated a record, the formula field value did not appear in the streaming event.
As this formula field was a required value in our integration, the fact that it was missing caused the integration to break. The simple solution was to make this formula field readable by all users.
In summary, there seems to be a subtle change in the behaviour of the Streaming API between Classic and Lightning interfaces. The following is not an authoritative statement, but from my testing it appears that …
In the Classic interface, the fields available in the streaming event are determined by the permissions of the user subscribing to the PushTopic channel.
In Lightning, the fields available in the streaming event are determined by the permissions of the user generating the event.
A relative with low vision recently needed a landline phone with programmable buttons, so they could easily call family members with just the press of one button. In my cupboard I had an old Alcatel TF200 phone (from Telecom Australia) that had 10 programmable buttons. I couldn’t find a manual for this phone online, but with experimenting I found that programming the buttons was a matter of lifting the handset then …
Press the “Store” button.
Press the digit buttons for the number you want stored.
Press the programmable button that you want the number stored in.
I noticed in the paper this weekend that the property known as “The Grange”, in Queens Rd New Lambton, is up for sale. This house and surrounding area was originally owned by William Thomas Dent, who was Secretary of the Northumberland Permanent Building Investment Land and Loan Society for 43 years.
“The Grange”, New Lambton
The building and land was sold by Dent in October 1921, purchased by the Newcastle Hospital Board for £4387. They planned to convert the property into a convalescent home.
“The Grange” in New Lambton in 1921, purchased for use as a convalescent home.
The planned conversion of “The Grange” to a convalescent home never happened, as the following year the hospital board purchased Lambton Lodge (the former home of Thomas Croudace, manager of Lambton Colliery) and developed it as the convalescent home instead. With “The Grange” property now surplus to requirements, the hospital board subdivided the land, and in June 1930 offered for sale 25 blocks of land around the original house.
The Grange Subdivision 1923.
W T Dent moved to a house in Curzon St New Lambton, where he died in 1942.
W T Dent properties in Curzon/Curson St New Lambton.
The other William Thomas Dents
The William Thomas Dent (1870-1942) who owned The Grange is not to be confused with his father, also called William Thomas Dent (1844-1901) who was secretary of the building society before his son, during the years 1877 to 1899. William Thomas Dent senior was the fifth Mayor of the Lambton Municipality and was instrumental in the erection of the Lambton Park Rotunda, and has his name in the ornamental ironwork above the entrance.
“W T Dent Mayor” on the Lambton Park rotunda.
Additionally note that the William Thomas Dent (1870-1942) who owned “The Grange” also had a son called William Thomas Dent (1901-1930) who predeceased his father, aged just 29.
[Note that the birth year I have stated for the three W T Dent’s above are approximate only, based on their age reported at their death.]
This week at work I struggled with a Salesforce Flow that I was trying to delete, but couldn’t. It seemed to be a bit of a ‘zombie’ Flow, that was a little bit alive and a little bit dead. It all made sense in the end, but when I was in the middle of it all, it seemed inexplicable.
It started with a custom field that our company had added some time ago, which was no longer needed and I wanted to delete. On trying to delete the system wouldn’t let me, saying that it was in use by a Flow. I clicked on the “Where is this used?” button which identified that the field was referenced in a flow.
Clicking on the hyper link to the Flow, opened it in the Flow Builder, but that interface does not allow any way for the the Flow to be deleted.
So I went to the Setup interface, to the Flows menu item to delete it. But although the Flow clearly existed (I had it open in Flow Builder a moment ago) it wasn’t appearing in the “All Flows” list for me to delete.
Next, I thought I’d try to delete this zombie flow by using a metadata deployment. I use the Gearset tool for deployments, and by comparing a sandbox Org without the Flow to the one that had the Flow I generated a ‘delete’ type deployment … which then failed with the unhelpful error message “Insufficient access rights on cross-reference id”.
Eventually I figured out that the Flow couldn’t be deleted because it was referenced from a Process Builder. When I had located and deleted that Process Builder the ‘zombie’ Flow disappeared, and I was then able to delete the custom field. What made things tricky was that it wasn’t the latest active version of the Process Builder that referenced the Flow, but an earlier inactive version, so I had to search through all the earlier versions to identify the one that needed to be deleted.
The bottom line is that Salesforce won’t let you delete something that is referenced by some other design element. That’s a good thing. But the bad thing is that it can sometimes be hard (and non-obvious) finding what exactly is referencing the element you’re trying to delete.
I get some amusement by pondering that somewhere in the world, there is someone whose job is to come up with names for new prescription drugs. Of course there a few basic rules in naming a new drug …
it must be memorable
it must be easily pronounced
it must be sufficiently distinct from existing names
it cannot spell or sound like a rude word in any of the hundreds of languages in the world.
But the most important rule of all is …
the name must be able to be credibly used in the title of a Doctor Who episode.
To illustrate my point, click on the button below to show an actual Doctor Who episode title, with one word substituted for an actual prescription medication sold in Australia. Doctor Who fans can try to guess the real title.