Salesforce and Open Source
With the ecosystem growing up, there are more and more people joining from other backgrounds who are keen to reset their new life to old habits... Fair enough, this is beneficial, in theory, to Salesforce...
In theory only, since Salesforce as a platform offers a particular approach that needs, and this is very important with SaaS, to be respected rather than challenged (get the new ecosystem to act like the old one). This post is about side projects, typically open-source and often hosted on GitHub.
Who Will Support You?
One of the great things about Salesforce is that its maker used the cloud computing architecture to provide free-for-life developer editions. As a result, many of us think we can have a copy of the office org on our laptop, at home, etc...
There is, at least, one invisible difference between a production org and a developer org, the relationship with Salesforce. A production org is supported by Salesforce, a DE org is not. So, typically when an add-on is developed (on a DE org) and distributed, possibly for free, although it may be compatible with your production org, as the production org owner, you must be asking yourself "who will support us is this add-on is going pear shape?". If you cannot answer the question, you may want to stay away from it. After all, your production instance is not a toy, it's the heart of your business and your role is to protect its integrity.
Who Will Refund You?
Some browser extensions or Salesforce AppExchange add-ons even touch your data. Again, you want to be sure that this will be done in a serious way and that if something goes wrong in production you will be provided with compensation or the capability to roll back. Ask yourself: "who will refund us if this add-on is incorrectly impacting our production data (or existing configuration)?". Again, if you cannot quite answer this question you may want to avoid "the improvement".
领英推荐
Proposed Approach
Try and come up with a rules book, which may be different from my above proposal, for the integrations you are authorising (above: avoid the red arrow "write" projects). The good thing is that you can justify all of these rules once and for all. You can also refine your document in time if need be.
Useful Resources
Here are some examples of great freebies for us Salesforce professionals. Jump in and look around but always think of the possible production impact.
Summary
Don't just accept a new free tool or app to work on the Salesforce platform because it's cool or proven to be widely adopted. Always think of the worst-case scenario and the impact it could have on your production org. Who will come to your rescue if things turn bad? Decide if you are happy to put your neck on the table for the pleasure to use it?
Senior Program Architect @ Salesforce | 22 Salesforce Certifications
2 年Trying an app in production is a none sense. I agree. You should be sure that it does not break the production and try it on a full sandbox at least. In some tiny use cases, you don’t have a choice because other systems involved in this app do not have sandbox mechanism. Additionally, I am amazed with customers installing installing my app OrgCheck in production. I really hope they follow your rule to make sure everything is ok before they install it in production. The cool thing though is that the app appears in all their sandboxes now!!!
Salesforce Developer at AmWins/Pluralsight Author
2 年Very much agree with you here. Buyer (or no buyer) beware