There's been a lot of discussion in the Salesforce space about Org Intelligence. Recently, I started an online discussion about Copado's Org Intelligence product and its less-than-ideal results, and I thought I should follow up on the topic and try to provide my own thoughts as to what org intelligence really should be.
Not an anti-Copado post
Before I start, I want to clarify that this is not an anti-Copado post. I respect all Salesforce DevOps vendors. Specifically, I believe Copado has done really amazing things for the Salesforce community, including:
- Creating many jobs that didn't exist before, specially in India where they are launching a new regional headquarters
- Some of the best minds in Salesforce DevOps, like Andrew Davis, have emerged from Copado
- Their branching strategy, while sometimes bloated, actually accounts for all the quirks of developing in Salesforce. Anyone who has sat down to seriously think about branching strategy in Salesforce will know that whoever created the Copado version, knew what they were doing and had a lot of insight.
Also, creating AI products is hard, and most of the industry is kinda winging it, so we are all bound to make mistakes. That said...
The trademark issue
The main problem I have is that Copado put a trademark on the phrase "Org Intelligence" and it seems they are more interested promoting the brand than in the underlying problems. Their landing page mentions 4 times they they coined the term, before they even explain what it does or who should care
Now, it's normal for vendors to have trademarks and IP. I know Metazoa probably has IP on its Shell Assets technology, and at AutoRABIT, we also have some IP related to some of the stuff we are doing for flagging risky permissions with Guard.
So the trademark itself is not the issue, it's how insistent the messaging around it is. And, if you are going to put a trademark on a piece of tech, then it better works.
As documented on the original LinkedIn post, I received poor results, and the AI-powered solution instead gave me a good recipe for South Indian Dosa with coconut chutney.
To be fair, Copado did provide some really good screenshots of their product working well, and I'm happy to admit that the use cases are very interesting. Perhaps I simply had bad luck or there was something wrong with my org...Also, I respect Copado for putting this out there for free for all of us to test. That's not easy for a company of their size.
Unfortunately, I believe there was an opportunity to educate the market on intelligent org design and it was missed. Between trademarks and chutneys, we forgot to ask the real question:
What is Org Intelligence?
We can start with Copado's definition straight from their website:
Org Intelligence is the AI-powered foundation Copado created to give teams a complete, actionable understanding of their Salesforce environments.
Unfortunately, this doesn't tell us much. The definition however, does hint at the real problem here: Understanding a Salesforce org.
Not understanding the org in which you work on can be the one of the most painful experiences you can have as a Salesforce developer or admin. As I said in the "Do you work in a dirty org?" blog post, this usually happens when you work in a dirty org. How do you know you work in such org? When you feel like this:
When you work in a dirty org, nothing is predictable. Any change can break functionality somewhere else. Every "quick thing" becomes a whole project that needs to be tested end-to-end.
For those working in such orgs, being able to understand the org, and make changes with confidence, is indeed a game changer.
However, I argue that we while these type of products are incredible useful, we shouldn't be at the mercy of them. Ideally, we don't entirely depend on a product to be able to make sense of our Salesforce org.
Ideally, every design decision that we make, from creating a new picklist value, to introducing a new integration, is made with care, and results in a clean architecture that helps the org "explain itself".
The screaming architecture
In the Apex Well-Architected Framework, I introduce the concept of a screaming architecture (not a term coined by me of course...) where the way we organise Apex classes into sfdx folders makes the architecture of the org obvious. Anyone looking at the codebase can immediately get a clear picture of how the org is configured.
For example, I can immediately tell that the org is used for Customer Support, and that we support several use cases, such what should happen when a case is closed.
I believe it's possible (to some extent) to expand this concept to all areas of a Salesforce org.
For example, if all fields follow specific conventions around names and descriptions, they can "explain themeselves". The same is true for Flows and their elements.
It's even possible to add comments in a validation rule to help other users (and LLMs) to understand the logic.
/* Validation Rule Name: Ensure_Amount_Positive */
AND(
/* Check that Amount field is not blank */
NOT(ISBLANK(Amount)),
/* Check that Amount is less than or equal to zero */
Amount <= 0
)Org intelligence is not enough
So, while org intelligence products can help speed up the process of understanding a Salesforce org (specially one that you just inherited), we still need the thoughful software design of humans to ensure that moving forward, the org allows us to intelligently make decisions.
This discussion reminds me of FFLIB, and how it tries to position itself as a solution for Separation of Concerns. In other words, use the framework and boom: You have separation of concerns. This is false. Separation of concerns is an outcome. One that emerges from applying many different principles of modularity and good software design.
I believe the same may be true for org intelligence. Real org intelligence is an outcome. One that emerges from a daily and never-ending effort to ensure our org's architecture is simple and obvious.
The best of both worlds
Obviously, I'm not saying here that good software design is a replacement to any type of org intelligence product. The best outcome is probably achieved by using both things:
- Have a process to make thoughtful designs across your org
- AND use a product like HappySoup.io or Copado's new org intelligence to help you make sense of past design decisions
I can imagine that any team that does these 2 is really well positioned to evolve the org with confidence and provide a lot of business value.