Salesforce has a large number of security features and the configuration and use of these features are what makes the Salesforce platform so appealing for developers.

The infrastructure allows developers to solve business problems rather than spend time creating and maintaining “infrastructure”!  It’s one of the reasons I love the Platform.

While Salesforce has made great improvements to providing programmatic access to many of the platform features, the configuration of these security settings remain off-limits, the reasons for this are obvious but sometimes they get in the way – as in my last post of spam email checks and Remote Site settings.

Again this comes with a warning, this is not a recommended approach so if you’re going to use it – use it very carefully.

As a precursor, every serious Salesforce developer knows about the File based deploy using the Metadata API the API allows a zip package of files to be deployed to a Salesforce org. Most enterprise organisations have implemented their CI/CD practices with the ANT wrapper to this call (a practice I strongly object to, but that’s for a later post).

Remote Site settings can be deployed using the deploy method, to do this we need to consume the Metadata WSDL and then create a zip package. First problem is, there is no zip file support on Salesforce, second problem – consuming the WSDL in Salesforce is extremely time consuming and involves a lot of manual editing.

Fortunately though, all of the hard work has been done by the team at along with some support from Pedro Dal Col & Pliny Smith.  If you’re interested in top end Salesforce development then Andrew Fawcett’s blog at is the place to go.

After downloading the apex-mdapi repo you will be left with a MetadataService and associated classes, to get a clean deploy I needed to tweak the MetadataServiceExamples.cls a little.

With this framework in place – its now possible to do a deploy of code from your Salesforce org as per below


MetadataService.MetadataPort service =  MetadataServiceExamples.createService();

service.SessionHeader = new MetadataService.SessionHeader_element();

service.SessionHeader.sessionId = UserInfo.getSessionId();


MetadataService.RemoteSiteSetting remoteSiteSettings = new MetadataService.RemoteSiteSetting();

remoteSiteSettings.fullName = A_Unique_Name’;

remoteSiteSettings.url = urlEndpoint;





MetadataService.SaveResult[] saveResults = service.createMetadata(new MetadataService.Metadata[]{ remoteSiteSettings });


It’s also possible to remove the Remote Site settings – and thus the start of our problems as we can now dynamically change the running security profile of Salesforce through code.

MetadataService.DeleteResult[] deleteResults = service.deleteMetadata(‘RemoteSiteSetting’, new String[] { remoteSiteSettings.fullName });


It is important to note that the deploy happens using the running users credentials, therefore I recommend that if you have to do this – lock the user down to the known IP Address range and make the user API only.

Next post – I’m actually going to post on something that is architecturally endorsed and best-practice.


Leave a Reply

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