Consideration for Employee Hub Product

As a side project, I volunteered for defining the use cases for prospective/employee engagement portal few years ago. While HR Management system (e.g. PeopleSoft, workday, inhouse custom tools) provided variety of features but there were certain gaps related to employee engagement which employee hub product was expected to handle. Salesforce was intended as evaluation platform for building the product proposed for specific business unit. As I see, some of the use cases are still valid and up for grab.

Problem Statement

Track and monitor prospective "candidates" from interview shortlisting to offer acceptance

Engage actively with prospective "employees" from offer acceptance to onboarding phase

Address challenges/request from employees and provide a platform to collaborate on queries as cloud-based delivery rarely had team collocated.

Lack of engagement/communication touch points was causing disconnect at each level and high churn rate (declines/separation)

Business/Working Model

Prospective candidate list received from various channels were managed centrally on organization career portal and later exported into file and shared with respective talent units tagged to horizontal. Same file was used to manage the recruitment drives.

Manual process for assignment of candidates for interview process, capturing feedback on paper or online form/excel sheets

Connects with prospective candidates (PC), prospective/current employees (PE/E) primarily driven via the talent/human resource management team.

Solution Proposed

While it didn't reach till the solutioning stage but back of mind using process automation to track different stages of engagement was certainly there. Key considerations were-

• Assignment rules to ensure there is no duplicate assignment of candidates with predefined forms/screen flows to capture feedback. 
• Conversion from PC to PE on selection with further tracking in separate object to address communication challenges. 
• Using activities to track list of items needed for onboarding process and to notify/email relevant units for smoother onboarding (like assets team for Laptop; security team for ID card, etc.). These regular connect and activity closure were expected to give an implicit indication on PE final conversion to E. 
• Collaboration via chatter/private group to handle discussions related to projects and unit activities. 
• Using email templates (for each communication type), auto assignments rules (for assignment of PC to interviewer or PE to a buddy), process builders, validation rules (to limit business rule violations), data loads (for capturing the candidate details), knowledge article for FAQs/documentation and so on. 

Cost of licenses, license type (community/platform/salesforce) and interaction between entities were not considered in initial stage.

L1 Use Cases

There were two broad level processes/use cases which product intended to cover - 

Employer key problem area - 

• Candidates not turning up for interview (Outside the scope as handled by talent team but reverse engineering to revise the plans).
• Prospective employees declining the offers.
• Tracking accountability of interviewer for hiring only genuine candidate (principal-agent problem).
• Last but not the least - driving engagement at project/unit level to address disconnects.

Employee (PE/E) key problem area - 

• Lack of feedback or input from Employer on processing status of candidature for both selection/rejection scenario.
• Disconnect and lack of communication from offer roll out till joining (this also led to deflection partially with trust as one of many other reasons).
• Lack of touchpoints and navigation guidelines (while these are covered during induction but connect goes for toss).
• Single platform for collaborating with point of contact for typical concerns faced by employees (e.g. continuous learning/certifications, policy links, project status, project documentation link, templates to be followed and so on).

Epilogue

While engagement was shelved after initial discussions and I too moved to another initiative, but got interesting insights while evaluating various use cases and capability mapping. 

Irrespective of tech choice (JS, Java, PHP or Salesforce) and associated cost it could have been an exciting product/idea to work on as it intended to cover some of the problem area industry wide. Some of the companies in 'best companies to work' list which I know indeed work on giving holistic candidate/employee experience and potentially the reason why they are in the list. Value based analysis (Anderson & Narus; Gyan Courtesy - Prof DVR Sheshadri) for any offerings is the key. :)

Designing a simple approval app

Few year back had an opportunity to design M&A solution using Salesforce Lightning. Lightning was just introduced feature (Dec'15) and many of the so called base features of classic interface weren't available in lightning. After 5+ years there are few which are still in wish list. Mobile development wasn't mainstream and was not even considered in initial stage of plan. It was more of a strategic initiative ("cash strapped") to evaluate the system capabilities before putting more money or expanding. A high stake project considering user base involved for the life sciences/medical device organization. 

Problem Statement - 

• Client's innovation unit was handling multiple opportunities throughout the year.
• Each opportunities depending on their deal size (<1 Mn to >250Mn) had different approving units going up-to group CEO
• All such approvals and reviews were happening over mails with no automated option for reminders or tracking mechanism to get real-time status of opportunity.

All this was leading to loss of potential acquisition opportunities to competitors. 

Business/Working Model - 

• The overall model was classified into two broad area, typical of any acquisition process - Early Stage and Late Stage with sub-classification on Non Binding Term Sheets (NBTS) & Contracts deals.
• Each deal type were further classified depending on funding source and associated units which had another sub-classification based on deal size range - <1 Mn, 1-10, 10-25, 25-50, 50-100, >100 Mn
• The approval matrix and groups were different for each deal type/size and required either serialized approval or parallel approval model

Solution Proposed - 

A simple model to capture deals within the system with OOTB file attachment capability coupled with dynamic approval and custom reminder mechanism. Custom object based parameterization. No considerations on mobile as neither holy document called SoW specified it nor client wanted it. Anyways mobile development those days meant either customizing compact layouts for SF1 layout or going SDK route involving android/iOS developers to build Native, Hybrid or HTML apps depending on client ask. 

Fast forward 2021 - 

If I have to design solution in present time, I will probably think about mobile app first and then anything else. While lightning was introduced keeping mobile ready app in mind but as quite a few clients looked forward to have their own branded app salesforce revamped the mobile publisher few releases back.

Design would have certainly changed taking into consideration GA features now. I will probably go for metadata based parameterized solution. Will likely be using flows extensively for reminders instead of custom codes. incorporate state model, use feed driven approval as option and so on. And most importantly will probably evaluate mobile publisher capability to build the app which apparently give greater control and management of mobile app.

Fast forward future - 

And I am almost certain that even above solution will  look dull in another 3-5 years considering pace of technology evolution. May be system capability will get built to capture such opportunities automatically. Parameter based auto approval for low key items with random samples picked for evaluating the system decisions by stakeholders. 

P.S. - I was initially planning to write a note on mobile publisher capability and how easy it was for a not so techie guy like me to build an android app (prototype of course) but eventually got lost with the design and thought that how dull old solution looks once we have better technology available at our disposal. Last but not the least, detailed design was not given for obvious reason.

Salesforce Service Cloud Performance/Delighter Features

True to the core principle of Kano framework, salesforce product has evolved over the period to meet the basic needs, performance features and delighters for customers. Once delighters turn into basic needs, something new and interesting comes up again to keep the arena exciting. With increasing product portfolio with both organic and inorganic growth Salesforce seem to have identified the trick to select feature that can greatly enhance user experience. As per recent releases salesforce came up with few productivity features related to Service cloud to delight the users and customers alike. Some of it listed below that can help to cut down the customization and make application/product feature rich with little effort (read low code / no code).

1. Identifying Knowledge article relevant to the case to give faster case resolution – In many of the engagement you may have used once a delighter feature of knowledge sidebar which gave a quick option to agent to select suggested article (unordered set) or search for knowledge article and attach it to case or email response to take forward the case for closure.  Any requirement around auto association of article based on certain set criteria ended up getting into customization route. And then came then Einstein knowledge article recommendation that gives an AI based model which continuously gets trained with each agent actions on article attachment or downvoting. Advantage it gives over standard suggested article is that outcome of recommendation is an ordered set with highest match on top of recommendation bar and will potentially saves the costly real-estate.
2. Recommending probable picklist field value for case classification – Each second saved in resolving a case in service/call center industry counts a lot as each of those seconds by giving agents prefilled suggestion translates into millions of seconds for millions of cases addressed by the agents over a period. One such mundane and repetitive task is to fill some of the key fields on case which are useful for reporting purpose. Case Type, Sub-type, Reason, Resolution Type etc. which quite a few times left blank and hits on data quality. Only caveat to use this feature is a significant count of closed cases with relevant fields filled in (~4000) to train the model. But at same time model will get trained and start functioning with organic growth in data.
3. Identifying likelihood of case escalation or reopening – Nothing beats the customer experience and enhanced loyalty than timely response to cases without a need to follow-up. Knowing in advance which customer can potentially reopen cases or identifying in advance the complex cases which potentially escalate in future help in routing the cases to expert agent to give attention case deserves as well win the customer loyalty. In service cloud context, prediction builder comes handy which again gets trained organically but having a cleaned data set to train it greatly improve the outcome.
4. Einstein Reply Recommendation – Once a delighter feature called quick text for chat, email, etc. are slowly becoming a basic requirement. To up the game further salesforce has come up with reply recommendation primarily for chats. This gives an option to agent via side bar on possible response that can go for upcoming message from customer. To enhance the experience further sidebar gives opportunity to agent to edit the message before posting it. Unlike other features, here there is a mandate to have minimum number of chats replies available in system. It makes sense to include this once ample number of entries are available in the org and bring it in delta release to continuously wow the agents/customers.

While all these features greatly improve the experience it majorly feed on data. And, major issue with all data led models is – the models are as good as the input/training data. It always helps to have cleaned data to train the system and utilize the feature to full. If that is not the option, keeping those fields as mandatory and monitoring the data correctness in initial stage will serve as a good investment.

All these features typically come­­­­ along with Unlimited/Enterprise edition having Einstein service cloud feature license enabled. Bundled licenses typically comes at heavy discounts and certainly a good investment.

Details for implementing these features and associated prerequisite are available in reference links.

References –

• Kano Framework - https://en.wikipedia.org/wiki/Kano_model
• Licenses - https://www.salesforce.com/in/editions-pricing/service-cloud/einstein/
• Einstein Article Recommendation –
• Trailhead Link - https://trailhead.salesforce.com/content/learn/modules/einstein-article-recommendations-for-service
• Model Improvement - https://help.salesforce.com/articleView?id=sf.einstein_article_recommendations_improve.htm&type=5
• Challenges - https://trailblazer.salesforce.com/issues_view?id=a1p4V000001JilCQAS
• Einstein Case Classification –
• Trailhead Link - https://trailhead.salesforce.com/content/learn/modules/service_case_class
• Einstein Prediction Builder –
• Trailhead Link - https://trailhead.salesforce.com/content/learn/projects/prediction_builder
• Einstein Reply Recommendation
• Trailhead Link - https://trailhead.salesforce.com/content/learn/modules/einstein-reply-recommendations-for-service

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/

Salesforce External Object and Limitations

Note - Another attempt to dilute my blog page and also to keep it revived. Justifies the blog title of a random post :-)

I was evaluating the Salesforce external object, OData 2.0 based connector and its limitations for one of my engagement. While a lot of information was available but it was scattered with nothing concrete available to decide when to choose what. This is an attempt consolidate some key limitations and pointers to choose between the two options. 

On side note - I love writing and making stories out of everything (only when it is in writing)

Evaluation Area	Custom Object	External Object
Data Model	Needs explicit column and data type details for every field for which information needs to be captured	External object data model gets auto created as soon as the external data source is created and synced. Additional columns if created on external object within Salesforce will not get populated unless external system sends that detail. This will be an advantage as there is no additional information needed from market/requirement other than ODATA connector information and authentication details
Data visibility and sharing	Visibility can be controlled and customized as per requirement.	Visibility and sharing are “all or nothing”. Either all records are available in read-only mode or none of the records are visible. All external object data across the world will be visible to everyone. This might be a concern from requirement/legal perspective.
Record creation/editing/deletion	Record creation, editing and deletion permission can be defined as per requirement.	Records cannot be created/edited/deleted from salesforce and only read-only copy of data will be available. External object records can’t be created if user is not able to search the external id. Search will also be limited to 200 records at a time. Search filters will be limited to External Id (demo org has this limitation, but this needs to be cross checked). May be a concern from requirement perspective. Having said this there is a provision to write via custom route but will be having own limitations. Refer to salesforce link here for additional information on writable external object and additional license requirement.
Connectivity Constraints	Considering data will be inhouse there isn’t any concerns on external system availability.	Depends on external system availability/up-time for data visibility in search results. Row that gets returned can be relatively slower compared to search directly in external system. In case if external system connectivity is not working, user will keep on getting error about connectivity and will not be able to link external object record. May be a concern from requirement perspective. Search outcome will also be prone to system delays.
Storage Constraints	Considering data will be inhouse this will take consume available space. Each record takes almost 2KB and thereby total space consumed by roughly 60 Mn record is 12 GB of space	Storage is never counted against salesforce storage limit. Advantage as space consumed is 0 technically.
Validation and requirement rule on external object, reporting	Data is within salesforce and all salesforce-based features are available.	External object maps data from external system and thereby limitations of external objects are applicable. Activity, Attachment, Field tracking, notes, record level security, validation rule, workflow not available. Reporting record limit is 2K. Einstein analytics will be needed for reporting on entire data set. There is also limitation on custom fields. Entire list of limitation available in salesforce link here.  In case if there is a need for audit requirement, reporting or requirement validation on external object, those won’t be available. May be a concern from requirement perspective.
Call out limit (OData)	No such limit as record is stored within application	Each time user clicks on external object tab, view external object record, open a parent record to which external object is linked, search, access via apex will be counted against the limit. Limit is 20K OData call out per hour. Each time a parent record is opened with an external object record linked, will consume the limit. May be a concern from requirement perspective if application has a global footprint and high volume. Refer to additional details in salesforce link here.