We often hear the advice of 'Clicks, not Code' and '80% Config vs 20% Code'. Orgs are described, without a frame of reference as being 'very custom'. However, there is no generally accepted definition on how to calculate customization of an org. Assumptions about code brought from other platforms are being misapplied to Salesforce to the detriment of customers and end-users. This presentation suggests a framework called 'CEER (Config / Extend / Enhance / Replace). This framework breaks the dichotomy of code vs clicks and replaces it with an approach that reflects the true nature of a salesforce solution. It highlights low vs high-risk activities such as Custom Object vs Building a collaboration platform. It also allows you to understand how Managed Packages impact your solution. The result is the ability to describe your org in terms of real effort/outcome basis. Allow you to make statements like "30% of your overall solution and 70% of your effort was expending on replacing standard Salesforce functions." https://www.salesforce.com/video/7810482/

1. Steven Herod
Managing Director
Certified Technical Architect
@sherod

2. How Custom Is Your
Org?
A framework for measurement.
Dreamforce, 2019
Steven Herod

3. Motivations and what this presentation is not about
Config vs Code – the false dichotomy
The real questions I want to answer
Agenda

4. The things I’ve heard…
1. “We don’t want more than 20%
customisation”
2. “This org is too customized”
3. “You need to get approval before
we write code”
4. “We must have this…”
5. “I need 100 developers”
6. “We want to do full DevOps with
automated testing”
1. “Process Builder is causing significant
performance issues, but we aren’t
allowed to write triggers”
2. “They say its too custom, but they
won’t compromise on their business
requirements”
3. “These flows are impossible to debug”
4. “Why is this so hard to deploy, its all
config!”
5. “How do we even measure
customisation anyway?”
Business Owners Implementation Teams

5. What this presentation is not about…
Can I figure out how custom my org is by counting Metadata?
Don’t leave yet, there’s
another way….

6. Can you measure ‘customisation’ by counting metadata?
Picture
of a
Rocket
Has built a game
changing
domain specific
application
which has resulted in
40%
revenue growth with only
10% increase in costs to
service
Has completely
rebuilt Sales Cloud
in Platform Licenses
to solve a basic
B2B Sales Scenario
440 256,990
“Simple Org” “Complex
Org”
Super Duper Score: Super Duper Score:

7. Add to that, the No Code / Pro Code argument
There’s a out of the box
answer to every problem.
Customisation is a bad!
Salesforce is a platform for
coding your applications.
Developers Unite!
No/Low Code Pro Code

8. The dichotomy of Code vs Config
Configuration
• the particular arrangement or pattern of
a group of related things
Declarative
• denoting high-level programming languages
which can be used to solve problems without
requiring the programmer to specify an exact
procedure to be followed.
Customization
• the action of making
or changing something according to the
buyer's or user's needs
Code
• a language used
to program (give instructions to)
computers

9. The false dichotomy of Code vs Config
Configuration
• the particular arrangement or pattern of
a group of related things
Declarative
• denoting high-level programming languages
which can be used to solve problems without
requiring the programmer to specify an exact
procedure to be followed.
Customization
• the action of making
or changing something according to the
buyer's or user's needs
Code
• a language used
to program (give instructions to)
computers
Good Bad
“A false dichotomy is typically used in an argument to
force your opponent into an extreme position -- by making
the assumption that there are only two positions.”

10. The real questions I believe we need to answer
• Did the products we bought deliver the capabilities
we need, or are we building compensations?
• Did our Product Owners align our delivered
product to the Enterprise goals/Principles we went
to market with?
• Are we understanding the trade-offs we’re making
when making user stories/solution choices?
• Is our solution right-sized to our problem?

11. Does what your business needs
• Function
You meet your run cost targets
• Headcount / other operational costs.
You meet your business agility goals
• Speed/Confidence of changes
You can maintain and sustain it
• Skillset/Skill mix/Skill levels
Aiming for the Goldilocks zone

12. “Of the 325 capabilities that our Salesforce instance provides, 100 are provided by
Configuration, 100 are provided by Enhancements via managed packages, 100 are
provided by extension of Salesforce (using code and config) and we replaced 25 of
standard functions with our own unique implementation (using code and config). By
the way, I have graphs”
What we want to be able to say

13. Introducing CEER
Categorization and Analysis of
your solution.

14. Configur
e
Extend Enhance Replace
Not ‘Code’ vs ‘Config’ but CEER
Why you bought Salesforce

15. Configure
Examples:
• Default Lead Owner
• Field Level Security
• Creating page layout
• Creating a custom Lightning App
• Creating List Views
Long Term Impact
• Only when a feature is retired
• > 2 notice of depreciated features
The functionality is
supported using ‘no logic’
setup of Salesforce

16. Extend
Examples
• Declarative
• Flow and Process Builder, Workflow Rules
• Custom Fields
• Code
• Lightning Components
• Apex
• Long term impact
• Minimal, assuming use of public API’s, published best practice
Logic and data
processing functionality
Almost everything goes
here.

17. Enhance
Examples
• Conga, CloudSense, Vlocity.
Declarative
• Basic Configuring Conga
• OmniScripts
Code
• Conga Template Definition
Long Term Impact
• Minimal, assuming the use of public API’s, published best practices
however, vendors do differ from Salesforce in their Product
Roadmaps, Vendor input should be provider
The introduction of ISV
and off platform solutions

18. Replace
Examples
• Use of JavaScript frameworks to replace Lightning Web Components.
• Build your own Email Composer
• Build your own Forecasting
• Use of Apex Managed Sharing instead of Declarative Sharing.
• Custom SSO options.
Long Term Impact
• Medium to High.
• Custom features may be superseded by standard functionality.
• Security changes may render some feature replacements invalid
The replacement of any
out of the box
functionality

19. But, how do I apply this?

20. 5 inputs to the process
An expression of a capability or need
• A requirement or a user Story
An solution to that capability or need
• “How would we do that?”
An Estimate
• Days, hours, dollars, story points, fruit size.
A categorization
• This is CEER
An implementation method
• Declarative or Code based development.

21. User
Story/Requirement
The requirement in
the appropriate
format
The requirement in
the appropriate
format
The requirement in
the appropriate
format
The requirement in
the appropriate
format
Start with your expression of need…

22. User
Story/Requirement
Solution Note
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
Add your solution note

23. User
Story/Requirement
Solution Note Estimate
(Time, Story
Points)
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
2
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
5
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
5
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
12
Provide an estimate

24. User
Story/Requirement
Solution Note Estimate
(Time, Story
Points)
CEER
Categorisation
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
2 Configure
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
5 Enhance (Vlocity)
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
5 Enhance (Vlocity)
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
12 Extend
Give it a categorization

25. User
Story/Requirement
Solution Note Estimate
(Time, Story
Points)
CEER
Categorisation
CEER Method
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
2 Configure Declarative
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
5 Enhance (Vlocity) Declarative
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
5 Enhance (Vlocity) Declarative
The requirement in
the appropriate
format
Describe the solution
approach in a few
words
12 Extend Code
And an implementation method

26. Results: User Stories Count by Solution Type
23%
47%
23%
7%
Configure
Enhance (Vlocity)
Extend
Replace

27. Results: Effort by Solution Type
4%
21%
26%
49%
Solution Type Story Point Breakdown
Configure
Enhance (Vlocity)
Extend
Replace

28. What percentage of my solution is Code (By User Story)
20%
80%
Declarative vs Code User Story
Declarative
Code

29. What percentage of my solution is code (By Effort)
50%50%
Declarative vs Code Story Point Effort
Declarative
Code

30. Conclusion
Complexity is not a measure of
‘Customization’
Salesforce is a platform and a product,
embrace it.
What matters is that your solution aligns to
your principles and expectations.
Informed choices are better than