Salesforce as a technology has been in constant flux since beginning and is always driven by latest technological innovation/security consideration. This certainly has its own challenges but also gives fair opportunity to implementation experts by resetting the base every 3-4 years. While key principals of CRM were always intact but changes in process be it s-control or classic (VF/Apex) or aura (lightning) or LWC (lightning) always brought new unlearning/learning opportunities. In spite of ever changing landscape Orgs are still upbeat as salesforce is always backward compatible e.g. S-controls (precursor to VF) are still supported in some form and so are all classic implementations (potential opportunity lies on transformation side for classic product built during first half of this decade).
While relatively smaller problem is classic to lightning migration where salesforce has provided accelerator and detailed framework for migration that start with need evaluation to gap analysis to post migration validation (probably topic for other time) but probably a bigger problem is limitations in lighting versus classic applicable for new implementation. As it happens with any large product some of the feature missed getting noticed, which results in effort estimate changes from solution design to technical development phase (at least for now) for greenfield product implementation or transformation product (non-salesforce-based product to salesforce product). This limitation list too is reducing in size with each salesforce release considering complete focus on lighting since past few releases. Having said this, some of the limitations will never be fixed for lightning. E.g. famous JavaScript buttons code which were used to override buttons in classic interface. Not because of feasibility but primarily because of security risks associated with JavaScript buttons (potential access by XSS to DOM and BOM which comes implicitly with JS).
Few simple but costly changes encountered during one of the implementation -
- Salesforce support for lookup relationship on external object. Lookup search on external object is not available OOTB in lightning. This changes/increases the estimate drastically. Possible workaround could be creating a custom reusable lightning lookup field.
- Feed based layout for case still doesn’t support task and activities tab in feed view. A simple workaround would be to add a related list for activities which will potentially eats the costly screen real estate but will save from custom page layout. Additionally, as far as feasible always pick the feed-based page layout for cases.
- Feed and search are still not available in lightning. Probably this feature will get delivered in coming release taking into consideration high voting on idea exchange and there isn’t any workaround available as of now.
- Contact roles on account. Recommendation from Salesforce is to use contact to multi account setting in lightning to address this issue
- Close case layout has limited feature compared to full fledge setup available in classic. Possible workaround is to create a custom component to address the problem.
- Entitlement related list on contact and vice versa. Possible workaround could be to create a component for entitlement and add it on the flexi-page layout.
- Top-down tab-key order support in lightning page. Typically top-down tab-key ordering helps to navigate to next field below previous field and grouping. Unfortunately, there is no workaround for this other than using default left-right tab-key order in page layout.
- Another problem which has no workaround is phone number formatting. Phone number aren’t formatted properly for European number (or non-US countries) unless entered in specific sequence.
Last but not the least, some problems are lightning oriented and standard feature becoming nemesis for any custom development (as on date but may not be there in future). One such example is each lookup field give capability to create the record apart from search in create/edit screen. In case if you have created a custom action for creation, you must have to guide/train user not to use the inbuilt feature of creating new record directly from lookup if search doesn’t return any result. This also shows how salesforce wants everyone to stick to OOTB, but it goes without saying with scale and complexity of business scenario’s customization is inevitable. And that’s the fun part and keeps the playground exciting place.
Moral of the story – While drop the hint how a feature can be achieved during the requirement/functional discussions but be careful not to overcommit if you have seen something working only in classic. Better approach - never switch to classic layout for anything even though it is the most tempting thing to do.
References -
- Lightning vs classic gaps - https://help.salesforce.com/articleView?id=lex_gaps_limitations.htm&type=5
- S-controls - https://help.salesforce.com/articleView?id=dev_about_scontrols.htm&type=5
- JavaScript button risks and challenges - https://trailhead.salesforce.com/en/content/learn/modules/lex_javascript_button_migration/lex_javascript_button_migration_intro
- Lightning roadmap - https://help.salesforce.com/articleView?id=lex_roadmap.htm&type=5
- Challenges with close case layout - https://trailblazer.salesforce.com/ideaView?id=0873A000000cMWbQAM
- External object lookup issue in lightning - https://trailblazer.salesforce.com/ideaView?id=0873A000000CYrsQAG
- Top-down tab key order issue - https://trailblazer.salesforce.com/ideaView?id=0873A000000cMf9QAE
- Case feed search limitation - https://trailblazer.salesforce.com/ideaView?id=0873A000000E3c8QAC
- Phone number formatting issue - https://trailblazer.salesforce.com/ideaView?id=08730000000hE5jAAE