Accelerator Overview Org Health Assessment - Meetupfiles.meetup.com/5469722/Salesforce Developer User Group - Org... · the configuration data and access to code to compare against

Accelerator Overview Org Health Assessment

Elango Joseph Success Specialist

2

Introductions

www.linkedin.com

/in/elangojoseph

Elango Joseph Success Specialist

BACKGROUND

• 15+ years in Shaping long-term success for enterprises through Business transformation, Implementing Business platforms and complex Business integrations

• Currently focused on Salesforce Communities, Platform and Governance success

EXPERTISE

• Administrator

• Advanced Administrator

• Developer

• Sales Cloud Consultant

• Service Cloud Consultant

http://www.linkedin.com/in/bludwig

3

Agenda

Accelerators 4

Org Assessment Approach 6

Org Assessment Early Warning System Sandbox Architecture Complexity of Configuration Complexity of Code Other Configurations and Customizations

8

Key Recommendations 23

LTE

Mobile

Cloud

Connect With Your Customers in a Whole New Way

Accelerators

5

Targeted engagements that deliver the results your business demands

Delivers Customer-defined Business Outcomes

Focused on a unique and

specific customer need Delivered by

Specialists Provides a fixed set of

value-based deliverables

Accelerators

Org Assessment Approach

7

Org Assessment Approach Org Health Assessment Accelerator Approach

• Org Health Assessment accelerator involves the analysis on the health of an Org from a technology perspective

• Org Health Assessment include detailed analysis of the Org specifically looking for technical debt

• Org Health Assessment is carried out by sampling the configuration/code to get an overall health assessment

• Key Business Outcome of Org Health Assessment accelerator is to increase visibility into customer’s Salesforce Org health

Tools Used

• Adoption Metadata Tool: Key metrics that give insight into your org usage as compared to your industry peer group and what we

consider healthy

• Org Metadata Tool: Gives access to an Org’s complete configuration and code, however we do not have access to any Data. We use

the configuration data and access to code to compare against best practices

Assessment Areas

• Overall Org Health

• Adoption and Usage

• Sandbox Architecture

• Complexity of Configuration

• Complexity of Code

• Governor Limits

• Other Configurations and Customizations

Color Meaning

Indicates we are within a range we consider healthy

Indicates there are areas that require consideration, but doesn't fall

directly in our unhealthy range

Indicates there are areas that will require attention and should be

addressed

Org Assessment

Adoption and Usage

10

Early Warning System EWS data with key assumptions

EWS data with Key Assumptions

Usage Segments:

• Usage segments are determined using statistical analysis, knowledge of usage patterns, and

best judgment to determine the broad usage categories that customers can be grouped into.

Usage Segments vary according to the peer group of a customer

• Usage segments are categorized into:

Process Automation: Fully integrated Salesforce into their business processes and is

leveraging it to optimize their business processes

Process Management: Started to leverage Salesforce in their business processes. They

are using some workflows and started integration with other systems

Data Storage: Early phase of adoption and is using Salesforce to store data

Under Utilized: Just started implementation or is not using Salesforce in a productive

manner

Peer Group:

• Peer Group is defined by their Cloud, Edition, CFL Segment, Account Type

• Peer medians are only calculated for accounts that have more than 7 peer members in their peer

group (we've found they aren't statistically valid for smaller groups)

Licenses included/excluded for EWS:

• Salesforce user licenses are used to calculate the EWS metrics for non portal category

• Partner and Customer Community user licenses are used to calculate the EWS metrics for portal

category

Sample

11

Early Warning System (cont’d) Sample EWS data

EWS Data

Sample

12

Early Warning System (cont’d) EWS data with key assumptions

EWS data with Key Assumptions

True Login (Non Portal):

• Percentage of activated users who have logged in during the past 14 days

True Login (Portal):

• Percentage of activated communities and portal users who have logged in during the past 14 days

CREDS / User (Standard Objects):

• Number of standard object records created, read, edited / deleted per non-portal user in the last 14 days.

The following standard object types are counted: Leads, Opportunities, Contacts, Accounts, Forecasts,

Events, Tasks, Cases, Notes, Solutions, Attachments and Documents. These are browser-based edits

only. This number excludes edits via API calls. This is for non-portal users only.

CREDS / User (Custom Objects):

• Number of custom objects created, read, updated / deleted per non-portal user in the last 14 days. These

are browser-based edits only. This number excludes edits via API calls. This is for non-portal users only.

Records / User (Standard Objects):

• Number of standard record objects per user. Records of the following standard object types are counted:

Leads, Opportunities, Contacts, Accounts, Forecasts, Events, Tasks, Cases, Notes, Solutions,

Attachments and Documents. This is for non-portal users only.

Records / User (Custom Objects):

• Number of all custom record objects per user. This is for non-portal users only.

Report Views / User:

• Number of distinct reports consumed per user in the last 14 days. This is for non-portal users only.

Workflow Rules:

• Number of active workflow rules. This metric does not include approvals

Sample

Sandbox Architecture

14

Sandbox Architecture Current mix of available and in use sandboxes

Sample

Sandbox Type Developer Developer Pro Partial Copy Full

Available 3 2 0 0

In Use 12 3 0 1

Total 15 5 0 1

Sandbox Type Last Refresh

Full 08/26/2015 9:20 AM

04/05/2015 6:58 PM

Partial Copy Not Applicable

Developer Pro

09/03/2015 12:53 PM

06/23/2015 6:52 AM

12/09/2014 3:43 PM

Developer

06/15/2015 3:31 PM

03/10/2015 4:35 PM

01/20/2015 2:24 PM

12/19/2014 3:16 PM

12/09/2014 3:43 PM

11/25/2014 5:32 PM

11/10/2014 11:39 AM

09/17/2014 11:42 AM

09/12/2014 11:30 AM

07/08/2014 2:13 PM

05/08/2014 1:56 PM

Complexity of Configuration

16

Complexity of Configuration

Standard

Objects

Custom

Fields

Page

Layouts

Record

Types Workflow Validation

Sharing

Rules Triggers

# of

Records

Accounts > 100 20 30 1

Contacts

Opportunities > 100 10 20 20 > 1

Leads > 100 > 10

Campaigns

Cases

Complexity of configuration for standard objects – sample set

Caution Need Attention Legend:

Sample

Complexity of Code

18

Complexity of Code Complexity of apex classes, apex triggers and Visualforce Pages

Apex Classes Summary

• Estimated Code Coverage • It’s Less

• API Range • 12.0 to 35.0

• Change Management • Change management logs are not seen

• Code Documentation Quality • Inline code documentation are not seen

• Naming Convention: • Inconsistent naming convention is seen

• Standardized naming convention is not seen

• Large Apex Classes • Large apex classes with more lines of code are seen

Sample

Apex Triggers Summary

• API Range • 12.0 to 35.0

• Change Management • Change Management logs are not seen

• Code Documentation • Trigger documentation is not seen

• Inline code documentation are not seen

• Logic Filled Triggers • All the logic had been implemented in the trigger

• Dead Code • Commented code are seen

• Multiple Triggers executed for

same SObject

• Multiple triggers are seen to be executed for the

same Sobject

• Salesforce Record Id’s • Salesforce record id’s are hard-coded in the code

• Inactive Triggers • There are x number of inactive triggers

Visualforce Pages Summary

• API Range • 15.0 to 35.0

• Change Management • Change Management logs are

not seen

• Code Documentation

• Visualforce documentation is

not seen

• Inline code documentation are

not seen

• Readability • Needs to be improved

19

Performance and Scalability Request Count for the Instance

Sample

Concurrent Request Limit

Concurrent request limit errors happen when synchronous Apex requests (VF, WS, etc.) exceed 5 sec

20

Performance and Scalability (cont’d) Sample

Visualforce Top Hits

SOAP API Request Times

Key Metrics

Request_Time_Sum:

• cumulative total time in milliseconds

Request_Time_Avg:

• average total time in milliseconds to service the request

Request_Time_90th:

• 90th percentile for Request_Time

App_Svr_Sum:

• cumulative app server time in milliseconds

App_Svr_Avg:

• average app server time in milliseconds, subset of Request_Time

App_Svr_90th:

• 90th percentile for App_Svr

DB_Time_Sum:

• cumulative database time in milliseconds

DB_Time_Avg:

• average database time in milliseconds, subset of Request_Time

DB_Time_90th:

• 90th percentile of DB_Time

Request_Time ~= App Server Time + DB Time

Other Configurations and Customizations

22

Other Items

Other Items Risk Level

Profiles

Role Hierarchy Depth

Administrators

Delegated Administrators

Installed Packages

Unmanaged Packages

S-Controls

Critical Updates

Salesforce to Salesforce

Large Data Volumes

Skinny Tables

Custom Indexes

Acceptable Caution Need Attention Legend:

Other key configurations and customizations

Sample

Key Recommendations

24

Key Recommendations

Assessment Area Key Recommendations Current Assessment Key Next Steps

General

General:

• Develop a detailed plan to reduce the technical debt

• Implement project governance to monitor the software development life cycle to design and build solutions without any

technical debt

Implement the key

recommendations in the

short term and continue

monitoring in regular

intervals of time

General Recommendations

Sample

25

Key Recommendations (cont’d) Technical Debt

“[Technical Debt is] a design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more overall to do later than it would cost to do now (including increased cost over time)”

26

Key Recommendations (cont’d)

** Technical Debt is not only related to code **

http://acrowire.com/files/SEI.pdf

27


Areas where Technical Debt can be found

• Data model – lack of ongoing design and refactoring

• Old capabilities which were original developed which are now available out of the box

• Badly written Apex & Visualforce

• Writing code instead of configuration

• Development work instead of using in-built capabilities of Salesforce

• Over complex security due to lack of good design and understand requirements

• Data volumes

• Integration due to lack of strategy

• Out dated processes which have not been removed

• Over complex business processes – best to simplify and standardise will drive efficiency and cost savings

Examples of Technical Debt

• Far to many custom fields on Objects

• Too many Page Layouts & Record Types

• Too many Profiles

• Apex & Visualforce API versions

• Large Blocks of comment-out code

• In active Triggers

• Un used Custom Index’s

• S-controls

• Un-managed packages

28



Sandbox Architecture

Deployment & Environment Strategy:

• Strive to expand usage and knowledge of sandbox best practices

such that you are able to support multiple stream of project, support, and hot fix configuration / development

• Realize greater benefits from of Developer and Developer Pro Sandboxes via more focused data refresh strategies

Release Management:

• Configuration and customizations are being made in production

Org directly Define responsibilities of migrations (Admins, tech leads,

developers, release managers) • Define and implement release cadence to manage major, minor,

immediate and hot fixes

Technology & Tooling:

• Increase capabilities/adoption of Github/Jenkins/Ant for code-based deployments and diffing

General:

• Good sandbox design starts with the right naming convention

Need immediate attention

to address the key




intervals of time

Recommendations of sandbox architecture assessment area

Sample

29



Complexity of

Configuration

General:

• Remember the 25 Configuration commandments during the

implementation (https://help.salesforce.com/apex/HTViewSolution?urlname=SUCCE

SS-INSIGHTS-25-Configuration-Commandments&language=en_US)


to address the key


short to mid term and

continue monitoring in

regular intervals of time

Recommendations of configuration complexity assessment area (cont’d)

Sample

30


# 25 Configuration Commandments

1 Thou Shalt Always maintain detailed, thorough definitions in Descriptions

everywhere the field exists

2 Thou Shalt Never create duplicate fields in the same object

3 Thou Shalt Always keep end user experience in mind when configuring

(KISS principle)

4 Thou Shalt No more than 100 fields per object or consider secondary

child object

5 Thou Shalt Maintain a consistent, constant naming convention on all

metadata

6 Thou Shalt Never apply Field Level Security to ALL Profiles – be specific

7 Thou Shalt Never apply new fields to ALL Page Layouts – be specific

8 Thou Shalt Always include Record Types in Validation Rules to avoid

conflict

9 Thou Shalt Always document Requirements, Design & Testing

10 Thou Shalt Always be mindful of all Org limits

11 Thou Shalt Never hard code User or Contact names in picklists

12 Thou Shalt Always ask for Business Reporting Requirements up front,

not after project

13 Thou Shalt Never configure directly in Production

Recommendations of configuration complexity assessment area (cont’d)

https://help.salesforce.com/apex/HTViewSolution?urlname=SUCCESS-INSIGHTS-25-Configuration-Commandments&language=en_US

# 25 Configuration Commandments

14 Thou Shalt Never take field creation lightly. Consider the need, more generic

field names, use of field history tracking

15 Thou Shalt Always consider tidying up existing functionality when

configuring new

16 Thou Shalt Re-use existing functionality where possible instead of creating

new functionality

17 Thou Shalt Test, test, test – always thoroughly test every change no matter

how small

18 Thou Shalt Always check the System Audit Trail to know what metadata to

add to your deployment

19 Thou Shalt Always test in all available browsers

20 Thou Shalt Maintain certification

21 Thou Shalt Always consider your Data Model and Architectural design

before creating a new Object

22 Thou Shalt Always review Design before creating numerous custom fields

on an Object

23 Thou Shalt Never over customize Standard Objects

24 Thou Shalt No more than 10 Page Layouts or Record Types per Object

25 Thou Shalt Always Design first before Configuring

31



Complexity of

Apex Code

Code Coverage:

• Work on improving the code coverage to be greater than 85%

• Implement process to validate code coverage during the development life cycle

API Version:

• Work on updating the API versions to the latest API version. Fix

the API version issue across Apex Code, Apex Trigger and Visualforce Pages

• Old API versions are still supported, but they may not include the latest performance improvements and they may not provide access

to the latest functionality

Change Management:

• Change management on what’s changed in the code is not documented in Apex Code, Apex Trigger and Visualforce pages

Code Documentation:

• In line code documentation needs to be improved to allow other

developers to add future enhancements or fix bugs • Implement process to have Good software development practices

during the development life cycle


to address the key





Recommendations of apex code complexity assessment area

Sample

32



Complexity of

Apex Code

Naming Convention:

• Standardize the naming convention of apex classes, triggers and

Visualforce names

Multiple Triggers executed for same Sobject:

• Refactor the trigger code to allow a single trigger to execute on a Sobject

Implement Logic-less Triggers:

• Refactor the trigger code to implement logic-less trigger to

delegate the logic responsibilities to some other handler classes. This will help in better testing, code can be reused and will be

maintainable in the future

Others:

• Review and clean up the dead code from production • Review and remove the hard coding of Salesforce record id’s

Evaluate declarative capabilities for code customization:

• Consider using Lightning Process Builder and Visual Workflow for

Process Automation


to address the key





Recommendations of apex code complexity assessment area (cont’d)

Sample

33


# Apex Best Practices: The 15 Apex Commandments

1 Thou Shalt Keep thy code stupid simple (KISS principle)

2 Thou Shalt not put queries in loops

3 Thou Shalt utilize maps for queries

4 Thou Shalt use relationships to reduce queries

5 Thou Shalt not put DML in loops

6 Thou Shalt only use one trigger per object

7 Thou Shalt keep logic outside of triggers

8 Thou Shalt have a happy balance between clicks and code

9 Thou Shalt cover thy code

10 Thou Shalt write meaningful unit tests

11 Thou Shalt write unit tests before developing

12 Thou Shalt test all conditions

13 Thou Shalt never use dummy code coverage

14 Thou Shalt never test with existing data

15 Thou Shalt not introduce extra logic for tests


https://developer.salesforce.com/blogs/developer-relations/2015/01/apex-best-practices-15-apex-commandments.html

34


General Conventions – Sample List for Guidance

Create a header comment for every class and method that has the following format:

/* Class/method name:

Description: Author/Date:

Release: Purpose:

Change History: Date: Author: Descriptions: */

Remember good software development policies:

Naming conventions that have meaningful names and even consider Hungarian notation were the data type is included e.g. intMyAge. Upper case for constant variables

Properly indent and comment the code. All major blocks of code should have a comment

All if/for blocks should have comments Apex Classes should not be longer that 400 lines

Apply code structure best practices. Break the complex code into simpler, digestible pieces. This improves maintainability an d quality. Apex Methods should not be longer that 100 lines.

Apply code structure best practices. Break the complex code into simpler, digestible pieces. This improves maintainability and quality. Declare all variables at the beginning of each class

All instance variables must be declared either private or protected A class should have limited public variables except 'final' or 'static final'

Try to avoid public variables where possible


Sample

35


Assessment Area Key Recommendations Overall Current

Assessment Key Next Steps

Other Items

Profiles:

• Monitor the creation of new profiles and leverage more permission

sets

Role Hierarchy:

• Review the role hierarchy and weigh the performance trade-offs [https://resources.docs.salesforce.com/200/latest/en-

us/sfdc/pdf/salesforce_record_access_under_the_hood.pdf ]

Administrators:

• Reduce the number of users with administrator access and restrict administration access to the release management team

Delegated Administrators:

• Leverage delegated administrators as applicable

Installed Packages:

• Review all the installed packages and remove the unused

packages • For the actively used installed packages, make sure to use the

latest version of the package from the Salesforce AppExchange

Implement the key




intervals of time

Recommendations of other items assessment area

Sample

36


Assessment Area Key Recommendations Overall Current

Assessment Key Next Steps

Other Items

Unmanaged Packages:

• For the actively used installed packages, make sure to use the

latest version of the package from the Salesforce AppExchange. This is more important for the unmanaged packages

Critical Updates:

• Review and activate all the critical updates in the Org

• The critical updates page allows customers to control when a critical update will be enabled in their organization

Large Data Volumes:

• Evaluate and implement data archiving process to manage large

data volumes

Custom Indexes:

• Clean up the unused custom indexes working with the Salesforce support team

Implement the key




intervals of time

Recommendations of other items assessment area (cont’d)

Sample

Thank you