sfdc

Life in the SaaS Lane*

Scott S NelsonLeave a comment

TL;DR: The core SFDC CRM platform is an under-utilized way to build and provision robust, feature-rich, and cost-efficient apps with an appealing UX using mature low-code/no-code development.

Salesforce has grown from the $110m CRM ticker symbol established in 2004 to the over $150b1 best-in-class SaaS and PaaS leader it is today partly by continuously adding valuable capabilities organically and through strategic acquisitions. While all of the acquisitions have led to a broad suite of products, this article is focused on the under-utilized capability to provision apps using the core CRM platform.

A key factor to Salesforce’s popularity is the ability to customize how its products are used through configuration and custom coding. Its customers take advantage of this to manage the sales and support2 processes that make them stand out. Salesforce partners use this malleability to provide value-add functionality such as contract management, recruiting, specialized industry practices, etc., integrated into the Salesforce CRM platform. There is also a huge ecosystem of OEM ISV vendors that build solutions on top of the Salesforce CRM platform under their own names through licensing agreements. Most of these partner solutions have recognizable CRM process as part of their core offering or are immediately contingent to CRM processes.

But there is a great deal more that can be done with the flexibility provided by the Salesforce CRM platform than just CRM and its directly related processes. What has made the Salesforce platform so flexible is features such as Lightning Web Components, Lightning Pages, Flows, Connected Apps, and Platform Events. These capabilities make it very easy to create low-code/no-code (LCNC) apps that can be used by anyone in an enterprise with no knowledge of Salesforce or need to interact with CRM-specific functionality. Add to this the ability to create custom objects and develop custom functionality with APEX and SOQL and you have all the tools necessary to build applications that can do just about anything.

Does this sound familiar?

Let’s look at a common workflow for all businesses: an approval process. One person sends a request to another person for approval. In some cases, the first approver needs to get other approvals, or they may delegate the approval to someone else, or a series of approvers are necessary. Once approved, there is generally a completion action, such as being granted access to some application or having an expense reimbursed or a supply item ordered. Some of you may be surprised, even shocked, to know that there are organizations where that entire flow would be managed through email. Others will be wondering if there is any other way (we all have viewpoints based on our experiences).

For the folks who are surprised that such processes still happen over email, you may not be surprised that even processes managed through an application stall out because someone was on vacation or missed the notification to perform their task in the process, or someone clicked the wrong option and the flow terminated before completing with no notification to anyone. And even if all of that is a surprise, you still may start nodding your head to hear that the process is often accessed through an unappealing and inconvenient UI that’s difficult to understand without someone walking you through all of the steps. And if you are still thinking “no, my company has all that covered,” there is still the possibility that the perfectly working systems must be manually updated every 6 to 24 months because of some change in the vendor software it runs on. At this point, the hold-outs may very likely already be doing it with Salesforce.

Same SaaS, different view

This is not a new observation. There have been apps in the AppExchange for many years that provide solutions for non-CRM activities such as project management, employee onboarding, expense approvals, and asset procurement. Most major vendors provide an app to integrate their product with Salesforce. Yet enterprises themselves seldom take advantage of these capabilities with their own app development and management. One likely cause is the confusion around licensing. Users of specialized apps frequently do not require a full standard user license to be able to use an app deployed in Salesforce. There are many lower-cost licenses, the exact cost depending on an enterprise’s ability to negotiate based on other uses. Salesforce may be missing out on a lot of revenue in making these options difficult to reference and understand.

Even with a discounted license, the platform cost may be higher than other common options. Businesses that have a large license footprint with Microsoft or Oracle have app platforms available that, on the surface, may appear as more attractive alternatives.

While Salesforce is the most mature SaaS offering available (of the many articles that note SFDC as the first-ever SaaS provider, this article on Medium has the fewest ads or other self-promotion), enterprise software vendors such as Microsoft, CA Associates, and Oracle spend a lot of time, money (yours!), and effort convincing you to use their tools for everything. They have to push their offerings for a few reasons. First, while the companies themselves have been in business longer, most of their app offerings are either the result of an acquisition or a new option built to keep competition at bay. The tools themselves often have a negligible developer community, and there is no guarantee that an update in the next release will render a solution relying on them as unusable without extensive re-work.

Another reason major vendors provide low- and no-cost options for apps is they can make them easier to integrate with their own products. In some cases, the apps only integrate with their own products. This makes their options appear to be low-hanging fruit, though the ability to build something even marginally complex may require expensive training or consulting, and still require a migration to a future version or tool to maintain support.

Know the cost and the value of your options

Finally (for this article), most of the lower-cost tools from major enterprise software vendors have poor user interaction capabilities without extensive customization (and some do not even provide a customization option). Assuming the development cost was not higher (it usually is), how much value is the enterprise realizing from the lower license cost if users either don’t use the app or if using the app is more complicated than the manual processes they were using before?

While it is possible for some of these issues to be experienced using the Salesforce CRM platform, it is only because any tool can be used below its potential. Salesforce communicates potentially platform-breaking updates to every admin months in advance, and provides clear direction on how to address the changes. In some cases, they even create tools that will make the updates for you. There are thriving and growing communities for users, developers, and architects, plus active groups discussing specific features.

It is true that most solutions built to deploy as an app on Salesforce will only run on Salesforce, as with most other vendors. Salesforce does, however, make it very easy to integrate with other platforms where other vendors frequently only provide a similar level of integration ease with their own products.

If you build it, they will run

Distribution of apps can be managed in multiple ways, depending on the size and complexity of the app and the organization. Orgs with small development and administration teams can continue to be successful with change sets by following Change Sets Best Practices. Teams using DX can manage the apps as Unlocked Packages, and vendors can distribute the apps as always through App Exchange while gaining some customer support points by pointing admins to the lower cost license options.

If your organization is already a Salesforce CRM (Sales Cloud or Service Cloud) customer, weigh the options of using that same platform to build and distribute your next app on a mature, robust, scalable, and reliable platform for a lower TCO (even if you have consultants build it for you).

Notes

1 $163b as of this writing

2 and marketing, and analytics, and integration, and… but that’s a different topic.

* Title is my musical alternative title for this post originally published as SFDC PaaS beyond CRM which could also be SaaS, PaaS, or gas, everyone wants the best price 🙂

If you found this interesting, please share.

© Scott S. Nelson

5 considerations about low-code/no-code (LCNC)

Scott S NelsonLeave a comment

Developer shortages, shareholder demands, and digital-first competitors are a combination that fuels the most recent popularity boost of low-code/no-code (LCNC) solutions to business application needs. LCNC platforms are now widely used for custom software solutions and business transformation across industries such as healthcare, banking, finance, insurance, manufacturing, and retail. The idea is not all that new. I remember building some feature-rich functionality using MS Works back before we had Google to search for shortcuts on and AOL was mailing floppy disks every week to the same addresses.

The tools have been getting better and better over time, with a major acceleration in quality as developers began using drag-and-drop to quickly outline complex applications that could then be tweaked for robustness and complexity. These platforms now leverage visual interfaces and drag and drop interfaces, along with pre built components, to enable rapid application development and significantly shorten project timelines. Business spent tons of money on tools to make developers more efficient, so the tools kept getting better until they evolved into something that non-developers could use to create fairly sophisticated functionality (and the developers went back to the command line). Some of the leaders in the space are the Salesforce.com platform, Microsoft Power Apps, and Appian, to name a few.

LCNC democratizes application development by empowering business users, non technical users, and citizen developers to create applications quickly and easily, while professional developers and traditional developers can focus on more complex tasks. The adoption of low-code/no-code platforms is projected to grow significantly, with estimates suggesting they will be used in over 65% of application developments by 2026, driven by the need for agile delivery and faster development cycles.

Why you should be thinking about LCNC

It’s easy to see why business buyers are attracted to LCNC options. LCNC tools enable employees to quickly develop applications and create applications tailored to their business ideas and departmental workflows. These platforms empower employees in various departments to build tools that fit their specific needs, making it easier to innovate and respond to changing business requirements. Common internal use cases for LCNC platforms include vacation request trackers, employee onboarding portals, and project management dashboards. Developer shortage? No problem— your knowledge workers can drag-and-drop their own tools together. Need to improve margins? Tell your developers to always use clicks over code and reduce the time to deliver functionality. It is definitely that easy, because you saw a YouTube video where someone built an app in 10 minutes or a live demonstration at a conference where the presenter solved a problem in 20 minutes that your developers took six months to complete two years ago. You might still need developers for the really complex stuff, but now they can do more, faster, with fewer people, and why do you need architects anymore?

Now, in a quickly written post I might just say that the entire previous paragraph is describing something that only exists with smoke and mirrors and is mostly vaporware, and that you are doomed to difficult, time-consuming solutions. I’m not going to say that, but I hope you haven’t gotten rid of those architects yet, because they can help make the right decisions about clicks over code.

1. It’s never really no-code

Hopefully you have heard the expression “there is no cloud; it is just someone else’s computer.” Well, in that same pattern, there is no LCNC; it is just someone else’s code. The great thing about this is that when there is a problem with the code, or the code can add more features, you rarely need to make any changes to get those updates. However, there are always updates, because the people using LCNC always seem to find the limits of imagination applied to the underlying code, and then you can’t go any further until it is updated. And if there aren’t enough people sharing the same problem, that might be a long wait. Thorough testing will help find these limits and let you know if you need to go another way. Custom development and traditional software development remain essential for businesses seeking unique functionalities, competitive advantages, and long-term scalability, especially when highly unique or complex functionality is required. While LCNC platforms are powerful, they may struggle with highly complex algorithms or extreme customization, which may require traditional ‘pro-code’ development.

2. Easier isn’t always faster

Those slick demos on YouTube? Not all, but many, have been edited for time and flow. I watched a video about writing CI/CD configuration files recently and was both impressed and amused that the person kept using the wrong term and added a correction notice on the screen each time, at one point including “I don’t know why I kept saying the wrong thing.” This honesty was refreshing, and it bleeds over to the live demos, where clearly they aren’t editing out extra time or typical mistakes that result in doing something over. Live demos are the result of multiple rehearsals and (usually) careful selection of use cases that seem complex when seen for the first time, because the audience’s experience with that challenge is how hard it has been in the past, and they don’t consider the demonstration is of a tool that has been purposely designed to solve that issue. As Arthur C. Clarke said, “Any sufficiently advanced technology is indistinguishable from magic.”

That said, for the right use cases, LCNC will be easier and faster. The most important thing to remember about LCNC platforms is that they continuously mature. Just because it was not up to the task two versions ago doesn’t mean that it won’t fit the bill perfectly now. Take time to review the latest capabilities for any solution rather than falling back to an earlier approach. Conversely, don’t take LCNC claims at face value. It may not address your specific use case, or it may be an immature solution that will become unavailable in the next release.

While LCNC platforms empower citizen developers, they can also introduce risks such as shadow IT if not properly managed. Organizations should implement compliance and governance protocols when adopting low-code/no-code platforms to ensure best practices. Additionally, low-code/no-code platforms can significantly reduce development time and costs by minimizing the need for specialized development talent and reducing IT bottlenecks.

Finally, as you leverage LCNC for application development and automate business processes, it is crucial to prioritize documentation and monitoring to ensure that business processes are properly managed and maintained over time.

3. Faster isn’t always cheaper

“Act in haste, repent at leisure,” is both an incorrectly stated idiom and perfect description of why LCNC is not “eating the world” as software itself did. The bad rep of citizen development and shadow IT isn’t as much about solutions not being controlled by IT as it is about there being no organization of the solutions. Redundancies and inefficiencies always occur when there is too much reliance on LCNC, and these are the least bothersome of the side effects. More of a concern, and less obvious (until it is too late), is the lack of testing in non-production sandboxes. Automation is a key target for LCNC, and while it can make doing tedious tasks much faster while reducing the effort, it can also create havoc much faster with less visibility into the root cause.

Another ill side effect of LCNC is the attitude that since it is very clear how implementation is put together at the time, it will be just as clear to anyone else at any future time. This is usually an illusion (or delusion, depending on perspective). I know senior developers who, when rushed to deliver code without documentation, can look at something they wrote only a few days ago and have to laboriously trace everything back to remember why they wrote it. Now take something that someone with little software experience threw together (literally or figuratively) that did something really useful that people began to depend on, and then the person who built it leaves the company. Sooner or later, that solution will have an issue, and the odds are very much against someone finding where it is running, how it is working, and what needs to be fixed. Everything grinds to a halt until it is recreated from scratch. Even worse is when the orphaned solution clashes with another and very automatically creates havoc with the data in production.

This is not to say these tools and solutions aren’t valuable. They just need some supervision, documentation, and monitoring to ensure they are assets rather than liabilities.

4. Simplicity can be complex

This particular area is similar to the previous one, but a little different in how to prevent it from being a problem. Doing one simple thing with declarative programming (another type of LNCN) is very powerful in that saves time and decreases maintenance. So, doing many things, all strung together, is even better, right? Well, sometimes. Some processes require a lot of steps, and when initially building them out, where that is the only focus of the person doing the work, it all seems perfectly clear. But later, if there needs to be an update or an unforeseen problem arises, it can become extremely hard to trace through dozens (or more) configurations on a palette or file to locate where to make the change or fix the issue.

The solution to complexity from too many simple things strung together is to break the steps up into logical units. “Logical” may be in the mind of the developer, which is where architects come in. The steps can be categorized and segmented and then used (and re-used) in a simpler configuration. Sometimes steps are complex enough that it is better to have some custom code that can then be used by the configuration to complete certain pieces. Decomposition is something not often thought of with LCNC solutions, and it’s what makes the difference between great solutions and great re-writes following great disasters.

5. There is no one-size-answers-all

Well, like some of the shortcuts in the use of LCNC, this last item is really to round the list out to five. I think it is clear from the first four considerations that while consequences can sometimes be seen coming, and are always clear in hindsight, that a formulaic decision when to use LCNC and when to call in the senior developers and architects just isn’t possible.

There are, however, some safety rails that can help steer things in the right direction. First are enterprise architecture principles that reflect the organization’s culture around such solutions. Some businesses are built around a coding culture and LCNC needs to be isolated to specific usage. Other businesses are dependent on software to run but have a very small IT group where code is not their thing.

The reason I used the plural principles is that the best option will vary by context. A solution on the Salesforce.com platform should be declarative over custom … except when it is impractical. For example, one could probably manage very complex message routing or data synchronization using Flows, but Apex code will be much easier to maintain for the bulk of the solution. Weaving together declarative automation with custom code is often the most elegant solution to something complex, business critical, and not yet a full-fledged feature (or part of what differentiates your business). And check back each time you update it or need something that is new and similar to see if the Salesforce offering hasn’t since come up with an answer that will require less maintenance on your part. Missing the need to change the solution when the requirement changes is not limited to LCNC, though it is identified more quickly by the nature of LCNC being designed and built “top down” where custom code grows “bottom up”, delaying and obscuring the accumulation of technical debt.

Summing it up

Click, drag, and drop is what moved computers from the basement to the backpack, and even though “Internet speed” is a 20+-year-old term that now has different capitalization and meaning, we continue to look for ways to do more, faster, and easier. Low- and no-code is one way we continue to pick up the pace. We just need to remember to check that our laces are tied and we have the right shoes for the right track before really pouring it on to reduce the possibility of a face-plant at the finish line.

Originally published at https://logic2020.com/insight/low-code-no-code-considerations/

If you found this interesting, please share.

© Scott S. Nelson
Challenge Not Yet Complete

Salesforce Trailhead “Challenge not yet complete” most common causes

Scott S NelsonLeave a comment

Ah, Spring is in the air. So are arms, as people new to Salesforce throw them up during Trailhead challenges where they can’t seem to get the hands-on part to pass even though they see the result they expect.

The Trailhead modules and Superbadges are so well organized and written, it may seem like there is an instructor reviewing you submissions, but that would not be practical, profitable, or in the spirit of a cloud platform. The scoring is done by automated tests that are checking that things match exactly as the instructions provided.

The most common cause is that the learner has mis-typed a value provided, usually the API name (i.e., my_variable__c). Runner up to this is the experienced user who is new to Trailhead and uses their own naming conventions rather than following the instructions (been there, done that).

The third common cause is that the module content was updated but the test was not (doesn’t happen that often, but you can tell when there are a bunch of questions on the Trailhead Community about the same problem).

Here’s another I often see. Some of the lessons are re-used between modules and trails, or were once in a different order. Regardless of how it got to be, the instructions may say to create a new playground when one has already been created for the module or trail, and work done previously is required to continue.

A couple of similar issues to the above I have also seen is when there are steps described in the lesson content and the challenge assumes these steps were done in the playground. Alternatively, it is sometimes not clear to new Trail Blazers that the same playground should be used throughout a given module or trail, or they inadvertently select to create a new playground or select the wrong playground. Personally, I use a collection of Developer orgs instead of playgrounds to make it easier to go back and find something I had done previously, but I don’t recommend that for most beginners.

This is not an exhaustive list. If you got through it and still haven’t seen Assessment Complete! +500 points, read through the module from the start as if you had never seen it before. Depending on your input processing style, you may want to wait a day or two. Or post a request for help on Trailhead and be sure to include a link to the lesson and module in your request. And feel free to tag @Scott S Nelson.

HTH

If you found this interesting, please share.

© Scott S. Nelson
MFA

Salesforce MFA and the Salesforce Platform User License

Scott S NelsonLeave a comment

I’ve seen a lot of FUD around the new MFA requirements from Salesforce. Understandable, given there are many people tasked with managing this who do not have experience in managing it.

One common question is around API integrations and how to do MFA. While this can (and in some situations, should) be done, it is not required.

From Salesforce Multi-Factor Authentication FAQ:

Publish Date: Dec 13, 2021

How will Salesforce exclude MFA-exempt user types from auto-enablement and enforcement?

There are several user types, including API/integration, automated testing, and RPA accounts, that aren’t required to use MFA. We’re currently working on plans for how customers can exclude these types of users from future auto-enablement and enforcement milestones. We’ll update this FAQ and your products’ documentation when more information is available.

See also:

So, in conclusion just set it up with a Salesforce Platform User License, generate a token for that user, then use the APIs to login or login with username and Password+security token, depending on the application.

HTH
Regards,
Scott S Nelson

If you found this interesting, please share.

© Scott S. Nelson

Most Common Question about Salesforce Flows

Scott S NelsonLeave a comment

This is the most common question I see about Salesforce Flows, and was one of my first questions, too. To save me looking it up all the time, I’m storing it here on my blog…

Q: How to have a flow go somewhere other than the page it was called from at completion?

A: See Customize a Flow URL to Control Finish Behavior

If you found this interesting, please share.

© Scott S. Nelson