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.

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.

This is a work related techie blog post for the benefit of others who may experience the same problem.

We have a production Salesforce Org and a number of sandbox Orgs, all set up with a Salesforce “My Domain” and configured to use Single Sign On authenticating against Microsoft ADFS. On the weekend, after our sandbox Orgs got upgraded to the Summer ’19 release, we were unable to login to any of our sandboxes using Single Sign On. We were just getting a very unhelpful “An error occurred” message on the sign-in screen.

Comparing the Single Sign On settings in our Production Org (which was still working), I noticed that where the “Login URL” SAML endpoint used to have an “so=OrgID” parameter, this was now gone in the updated sandboxes. Jumping on to our ADFS management console, and editing the relevant Relying Party Trust to remove the “so=OrgID” parameter from the Endpoint was all that was needed to fix the problem.

Curiously, when I checked the release notes for the Summer ’19 update (which is 480 pages long!), there appears to be no mention of this change in Single Sign In configuration.