Thou shalt not alter what is set in Salesforce org’s foundation stone!
A Salesforce administrator, an Apex developer, a technical architect or an implementation expert – whatever your role is in our Salesforce ecosystem, you’ve come across the phrase “once enabled, this feature can NOT be turned off” in implementation guides and release notes. This post details a list of a few popular “you’re about to set this in stone” features that you need to treat with caution before enabling in your Salesforce org or when considering incorporating into your solution.
Some of these features might be a great fit for your solution and that perfect answer to all your business requirements prayers. However, before arriving at that conclusion, do your due diligence in researching the feature capabilities, dependencies, long term implications and test out the solution in sandbox environments following best practices. Accidentally turning on these features is not very common in Salesforce orgs that have well defined release processes and role structures (but I’ve heard it happen). And if you don’t have well defined processes and role structures, you’re asking for trouble.
1. Person Accounts
When enabling person accounts, Salesforce shows a warning message indicating that you can not undo the step. The user must understand at this point that they are indeed carving their decision in stone and there is no going back (at the time of writing of this article). The feature works great if it is indeed the right fit for your BOC line of business.
There can be instances where it is no longer the right fit. For example, when an organization tried a line of BOC program that did not work. Or, the volume of person accounts in the org does not make it a good candidate for the optimal solution. Or simply, the team/person that originally enabled the feature did not truly understand the long term implications. Whatever the reason might be, having person accounts enabled when not really needed for business can be a burden. Here are some of the pain points when person accounts are not needed but are enabled in the org:
- The person accounts feature is known to NOT work with a bunch of AppExchange apps and third party API integrations. Fast forward a couple of years, even if you decide that the ability to use those AppExchange apps is a higher priority, you can’t go back.
- Maintenance overhead for maintaining all the duplicate fields
- With person accounts enabled, contact OWD sharing is controlled by parent and cannot be changed.
- Data storage might be higher if you’re using person accounts but don’t need to.
2. Divisions
Divisions can be a great solution for organizations with extremely large data volumes. Organizations can segment data into logical sections, making searches, list views, and reports more meaningful to users.
However, enabling divisions is an irreversible action. Once implemented, you cannot revert back to a state that does not have division fields. Refer to this cheatsheet for the comprehensive list of considerations. A few key questions to ask yourself when considering this solution:
- Do we predict business requirements that demand data sharing across divisions? For example, shared accounts and shared opportunities cannot belong to more than one division.
- Do we have numerous users that would own data in several divisions?
- Do we predict data growth to be extremely inconsistent? Will one of the divisions be dramatically larger than the others?
If you answered Yes to one of these questions, you should probably consult your senior architect to understand your org’s LDV issues and determine if divisions can really benefit your organization.
3. Multi-Currency
Change is the only constant and such is the nature of the universe. Sometimes, business rules change, or businesses are taken over by other entities and it may no longer be practical to have multi-currency. Once multi-currency is enabled, even if your Salesforce org does not have any secondary currencies selected, the feature cannot be turned off again. However, if your users are annoyed with the ISO codes being displayed in UI, you can configure the setting ‘Show currency symbols instead of ISO codes’ as long as there are no secondary currencies selected in your multi-currency org.
4. Custom Fiscal Years
One more feature that you’ll be marrying your org to for all eternity. A couple of key considerations to keep in mind before enabling this feature:
- Several popular apps are known to NOT work with custom fiscal years enabled. Carefully consider the priorities if there are any AppExchange packages that are vital to your business now, or may be in the future.
- The only fiscal years available for reports, quotas, forecasts, and so on will be those defined by your organization.
- After enabling custom fiscal years, when you define the first custom fiscal year, all existing forecasts, forecast history, and forecast adjustments from the first period of that year forward will be deleted.
- Subsequently, when you define a new custom fiscal year, any existing forecasts, forecast history, forecast adjustments, and quotas for the corresponding standard fiscal year are lost.
More considerations can be accessed here. Although you cannot revert to standard fiscal years, you can define your custom fiscal years to follow the same Gregorian calendar structure as the Salesforce standard fiscal years.
5. Portal/Community
While you technically cannot delete the community, you can mark it Inactive so that no one accesses it. However, even inactive communities still count towards the Maximum Number of Communities Limit. This limit is much lower in sandbox environments and can be an issue. Also, once enabled, Portal User options appear in dropdowns for any User Lookup field created even if the portal is deactivated.
6. Quick Text
With Quick Text, agents can use pre-defined messages to your customers and update cases quickly and easily. Once enabled, this can’t be disabled. But, you can remove all quick text records and remove CRUD access to the object via profiles to effectively disable the feature.
7. Email-to-Case
After you enable Email-to-Case, you can’t disable it. However, you can turn off the on-demand service at any time.
8. Mydomain, Community Subdomain
This one is not really set in stone. You can contact support to change this if there really is a need. But if you are a big enterprise with other integrations that are based on unique domain name, changing it means an additional effort on all those fronts. Just do not to pick a random temporary domain name in a production org with a mindset that you can change it after a couple of months. It might be a bigger effort than you think.
Final Thoughts
Salesforce has done a great job of providing some flexibility with a few other features that used to belong to this category like territory management, customizable forecasting, forecast hierarchies, etc. If you’re in the boat of desperately wanting to revert one of these features, make sure you vote on the ideas in the community.
