Bright Ideas: May 2018

I’ve got a great idea! Well, technically Andrew Fawcett does. Over the years he has had countless ideas, and recently he and some other people had the (frankly fantastic) idea that he would be really good working at Salesforce. I’ve been “tailing” him ever since he jumped ship… So what’s he up to?

Well, this recently caught my eye on Twitter, and you know what – it’s a bright idea for sure!

My view is that this is something which was annoying Andrew for years and he decided to bring some attention to it. But maybe you don’t see the point quite yet, so let’s give it some context – here is how Andrew has framed the idea…

“An increasing number of solutions are emerging where Apex is being used to consume the Salesforce REST or Web Service APIs. These might be time saving applications that interact with the Metadata API or tools that help move data from one org to another by using the Salesforce REST API. Having to ask users to configure the appropriate Remote Site entry for a Salesforce server inhibits the ability for users to get started with such tools and raises unnecessary questions, when the end points point straight back to the Salesforce servers.

Please allow callouts to Salesforce APIs from Apex to be permitted without a Remote Site setting.”

So if your solution performs an external callout you need to specify details about the remote site that the Apex is calling out to (e.g. https://xyz.com). Nuff said?

But that’s not the real issue being addressed here. Take something like Declarative Lookup Rollup Summaries (Andrew’s extremely helpful app from his previous life). When you install it, it offers up a splash screen which prompts the installer to create a Remote Site Setting.

The devil is in the detail above, but here it is. It’s very common for apps to require some sort of configuration as part of the installation or ongoing app usage. In the case of Andrew’s app he is saving DLRS user configurations as custom metadata within the same org, so there is nothing sneaky going on here other than he needs to reach out to call the Metadata API and back in order to create custom metadata records in your Salesforce org. It’s the same org, so why do we need the hassle of creating and maintaining the Remote Site Setting – shouldn’t it just be allowed if it’s the same originating org?

Now, I would say that how and when to use Remote Site Settings is common knowledge to developers, but I would guess that Admins encounter this to a lesser extent and could potentially be caught out when installing something and missing the step to create a Remote Site Setting.

Here is another example, a cool Lightning Component which you can install from the AppExchange – Related List Grid.

Take a closer look at the below – there’s a very important step in the installation of the component to – you guessed it – create a Remote Site Setting.

So this is another solid example of some tricky extra step which would simply go away if this idea was to be implemented.

Maybe this idea is a result of Andrew predicting that as components grow and the pattern of leveraging the Salesforce REST API against the same org gets stronger, then one less thing to worry about when your building your Lightning Components has to be a good thing.

This is another bright idea, so let’s make it happen. Go here, add your vote and add your voice: Allow Apex to call Salesforce REST and SOAP APIs without a Remote Site Setting

 

Leave a Reply

Your email address will not be published. Required fields are marked *