Salesforce Evolution and Challenges with lightning for service cloud implementation

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

Disclaimer - What may be limitation/challenge today may not be a limitation/challenge tomorrow. Safe Harbor. Intent was not to highlight limitation or how salesforce evolved over the years as that is too big task. What are the salesforce help portal meant for :-)

Heroku a primer

What it Heroku? 

Heroku is cloud platform (platform as a service - PaaS) that lets companies build, deliver, monitor and scale apps. It is a polyglot platform and thereby gives option to developers to write code in language of their choice (viz. node, python, java, etc. or even a custom buildpack). A typical journey from code to app goes like this - 

build system receives the code (which can be on any language) > buildpack is fetched (specific to coding language) > language runtime is fetched (specific to coding language)> address dependencies > a slug (buildpack + code) is produced which is injected into a dyno to run the app

Dyno is heart of Heroku which is virtualized Linux containers that are designed to execute code based on a user specific command so that app can scale based on its resource demand. It is ephemeral in nature. It does have option for private dyno (available with enterprise edition) which gets its own dedicated virtual network (private space). Dynos can be scaled both horizontally (additional dyno) as well as vertically (dyno size - 512 mb, 1024 mb). This scalability mode gives adequate redundancy and reliability/uptime needed for high frequency portal (e.g. Ecommerce portal) and private mode ensure that data transactions are secure. 

Similarity with Salesforce Ecosystem

Like Salesforce AppExchange marketplace, Heroku offer element market to get addons/buildpacks from where readily deployable code and feature can be fetched and run it in plug and play mode.

Features - Heroku Data Services

Heroku offers fully managed data services which are designed to work together e.g. - Postgres (Managed Relational DaaS), Redis (Managed Key-Value Store as a Service - To distribute the job order or queuing) and Kafka (Managed Kafka as a Service - To manage continuous train of messages. Producer and Consumer are handled via the broker where topic-based entries are split into partitions) which are natively supported.

One interesting feature which comes with Postgres is - follower and fork feature which enables up-to-date read-only copy and snapshot of master database respectively. Followers comes handy for scenario to reduce load on master DB while Forking enables validating/testing the schema migration. Heroku Postgres hobby instance can be useful for stub/simulation-based development where data can be hosted on Postgres and accessed in Salesforce development via ODATA or plain integration (leverage dataclips as an API)

Features - Heroku Enterprise

Heroku Enterprise gives and added level of security feature by giving option to private spaces (topping with shield as addon). Typically, common runtime allows to run and manage dynos in single multi-tenant network in isolated setup with an option to receive communication only from routing layer. But on other hand private space has its own network, routing layer and control plane that aren't shared with other application outside the space and thereby giving additional benefit on top of common runtime. Dyno in private space can communicate with each other directly over private network unlike common runtime.

Features - Continuous Delivery/Deployment (Heroku Flow)

It brings together Heroku pipelines, review apps, Heroku CI and GitHub integrations into an easy-to-use structured workflow for continuous delivery. This close loop setup gives a near-real-time view of application followed by GitHub commit thereby other coding patterns capability to Salesforce to see the changes immediately followed by changes in configuration.

Where Heroku can be used?

Simple answer could be for any custom application for any purpose – be it to extend CRM functionality or to create industry defining B2C UX, or to do data transformation and cleansing, or data analytics or high capacity storage or transportation. But typically, while extending CRM feature or salesforce capability a typical question can come on utility of communities over Heroku. Salesforce Community cloud also give rich user experience and UI but depending on complexity of the use case or primary focus area one option over other can be chosen (e.g. if the application is primarily focused on core functionality coving UI/API then communities is preferred approach but if there is heavy dependency on public content, usage, large data storage or processing then Heroku based application is more preferred approach.)

Where from now?

This was just a tip of the iceberg to get started with Heroku and its utility. To get started with Heroku, signup for a free Heroku account here - https://signup.heroku.com/. Like Salesforce development edition trial org, Heroku trial instance is also available free of cost.

Additional Resources : -

• Refer to Heroku documentation @ https://devcenter.heroku.com/categories/reference 
• Heroku Success stories can be found @ https://www.heroku.com/customers/case-studies
• Partner resources are available @ https://partners.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A0000004nd8
• 12 Factor App (Design consideration in containerized world) - https://prezi.com/8uldpq91vm4e/the-twelve-factor-app/