Auditing a Salesforce Org

Functional Audit

One workshop mid-audit to discuss their process
One workshop after the audit to discuss findings, step forwards

General stuff to check

Administrator presence - Nb of admins, experience, etc. (https://help.salesforce.com/HTViewSolution?id=000007548)
Organization Security - Check the automated health check in Setup > Health Check
User-Friendliness - custom app ? limited number of tabs ? how many fields per page layout ? is LEX-enabled ? Page layouts make somewhat sense ?
Maintainability - using best practices, nomenclatures, not using old notes or old attachments, low-ish number of automations per object, good structure in automations if many, avoid multiple sources of automation on one object.
Usage - have users logged in in the past 30 days ?

Limits

Data limit - Setup > Data Storage
Storage Limit - Setup > File Storage
Object limits - Run Optimizer if possible or check each object limit.
APEX limits - API calls per 24h, errors when tracking a user, etc.

Security

OWD & role reviews
Review of Profiles & Permission sets, flag any VAD or MAD access
Review of any external access
Review Sharing Rules

Data Model

Review of limits and object usage
Review of field usage
Review of general architecture
Solution design of Refactoring if needed

Data

Duplicates ?
Reportable ?
Owners make sense ?
Old records ?
Quality ?

Automation

Number of Processes/Workflows per object
Process Builder best practice audit
Flow best practice audit

- How many flows are there ?
> few: not used, flag it as admin probably doesn't know about them, check how the flow looks internally to check
> medium: cna be anything, but OK
> A lot: are they well named ? If yes yay, that's generaly an admin that knows their shit. If not I'm in for a world of hurt straight out the bat.

- how big are the flows ?
> small : don't care
> medium: don't care
> big: see if there's squres i the same order a few times, that means they should be using subflows. you'll notice it
> huge: should be using subflows anyway

- variables
> no input variables : they're using it as a script, train admin, but at least it's easy shit
> only input variables : they ahve no idea wtf input vars do, train them and check the flow for other bullcrap
> normal usage: yay

- elements
> are the elements named consitently ?
>> Yes: yay
>> No: fuck

> are all elements present used ?
>> yes: YAY:
>> no: fuck

> are all elements that could eb reused reused, or are there a ton of throwaway elements ?
>> tons of shit that gets used once because they don't know how to sue assignemnts and vars: fuck
>> reusable stuff: yay


- structure
> are the DMLs outside of the flow main structure ?
>> yes: YAY
>> no: fuck

> Are there elements in loops other than assignemnts or decisions ?
>> yes: fuck
>> no: YAY

- maintainability
> can the flows be read ?
>> yes: pfiew
>> no: fuck

> do you knwo wtf they're here for in less than 30 minuets ?
>>yes: somebody did their job right
>>no: fuck

> are the structues of the flow consitent and make it easy t maintain (subejctive)?
>> yay
>> fuck

> are there flows that should eb APEX or other shit ?
>> yes: list htem, explain why they shoudln't be that way
>> no: cool beans

Validation Rules best practice review
Workflows review

APEX

High-level APEX review: naming, basic structure
Code audit: standard best practices, optimization
Architecture audit
Solution design of refactoring if needed

Generation of the Audit report