1. #tahoedreamin18
It simply works... until
it breaks

2. #tahoedreamin18
Daniel Stange
Technical Architect
die.interaktiven | Salesforce User
Groups
Found Salesforce boring in the dark ages -
Changed my mind.
Frankfurt, Germany User Group Lead
You can find me at @stangomat
Meighan Brodkey
Technical Architect
SR Consulting | Salesforce User
Groups
10 years in the ecosystem, from admin to
architect. Love the platform and giving back to the
the Ohana.
Seattle WIT User Group Leader.
You can find me at @MeighanSF

3. #tahoedreamin18
To build awesome and robust point & click
solutions, you need to think and work in
patterns Salesforce developers should know
by heart.

4. #tahoedreamin18
And we don‘t mean common Salesforce
developer patterns...

5. #tahoedreamin18
Reminder: SOME
Salesforce devs...
Do documentation
/*
* 2012 by Daniel
* TODO: docs
*/
Build for scale
for (Account a : accs)
{
update a;
}
Build unit tests
@isTest
...
i++;
i++;
Use inline comments
//doing some magic here

6. #tahoedreamin18
Every developer can do better...
Including you, no-code jedi!

7. #tahoedreamin18
Agenda
You can be a better developer without having to be a developer at all:
◇ Think and work in enterprise development patterns (...just without the code)
◇ Design
◇ Build
◇ Test
◇ Deploy

8. #tahoedreamin18
Great Patterns
◇ Change Management
◇ Documentation
◇ Consistency
◇ Simplicity
◇ Scalability
◇ Test-Driven

9. #tahoedreamin18
Change Management
◇ Restrict changes in productive org to Reports, Dashboard and List views
◇ Establish one user who authorizes the migration of any change to production
◇ Establish a consistent workflow to migrate your metadata
◇ Establish a consistent way to model data for your project

10. #tahoedreamin18
Documentation
◇ Knowledge about your org and changes has to be stored where it is accessible
◇ Index of objects and logic should be the minimum
◇ Aim big: Create full business process and implementation logic for new stuff and
add old stuff whenever you touch it
Little Helpers
◇ Elements Cloud (freemium)
◇ Config Workbook (app exchange)
◇ Wiki & Issue Trackers (e.g. Jira/Confluence)

11. #tahoedreamin18
Consistency
◇ Naming Conventions
◇ Data Modeling
◇ Layouts
◇ Establish Paradigms that your users can learn and recognize

12. #tahoedreamin18
Simplicity
◇ Choose simple and performant solutions
◇ Prefer accessible solutions
◇ Avoid monoliths - break down complex logic

13. #tahoedreamin18
Scalability
◇ Any logic has to work if you change one record, but also for millions of records
or thousands of users at the same time

14. #tahoedreamin18
Test-Driven
◇ Model your solutions to solve test cases
◇ Model your testing to stress every aspect of your solution
◇ Try to break your solution to smaller, testable parts and keep notes on how to
test them, incl. expected outcomes
Little Helpers:
◇ Metadata tools like Copado or Gearset offer test execution schedules and
change monitoring (partly even in free plans)

15. #tahoedreamin18
Design

16. #tahoedreamin18
Start with documentation
◇ User Story Pattern: “As <Person> I need <Functionality> to
<Problem to be solved>”
◇ Acceptance Criteria
◇ Add a solution design and/or flow chart, entity-relationship
diagrams etc.
Little Helpers:
Agile Accelerator (AppExchange)
Issue Trackers (e.g. Jira)
Copado Change Management (AppExchange)
elements.cloud / gliffy / LucidCharts

17. #tahoedreamin18
Inspect existing logic
◇ Make sure you understand any logic that already exists for
the relevant objects
◇ Document your findings, if no docs are available yet
◇ Consider modularizing and/or extending existing logic

18. #tahoedreamin18
Choose your toolset
◇ If possible, stick to one automation tool per object
◇ If possible, use one master process per object and “handlers”
to extend the master process
◇ Don’t be afraid of Flows
◇ … but try to use the most simple tool to solve a problem
Visit David Liu‘s session today:
Clicks vs Code – which one should you choose?
5:10 pm, Sand Harbor II

19. #tahoedreamin18
Caution
when mixing automation tools.
(Apex often adds an explosive
component)
Hidden gem:
Perspectives in the Developer Console allow you to
inspect the execution of your logic.

20. #tahoedreamin18
Plan for Scale
Make sure everything can handle
at least 200 records at a time.

21. #tahoedreamin18
Be specific
Use specific Entry Conditions
for Automations to reduce
workload and “false positives”

22. #tahoedreamin18
No Apex,
No Limits?
Declarative tools consume
governor limits and are subject to
platform restrictions

23. #tahoedreamin18
Shared ressources
Whenever one or more records are created, updated, deleted, undeleted
◇ all logic shares limits in a single context
(except managed packages)
◇ 50,000 records can be loaded in 100 operations
◇ 10,000 records can be changed in the database in 150 operation
◇ if more than one record is sent to the database, up to 200 records are
handled at the same time
◇ you cannot edit System data (e.g. Users) and regular data (e.g.
Opportunities) in the same context (“mixed DML”)

24. #tahoedreamin18
Build

25. #tahoedreamin18
You need a
sandbox
NO EXCUSES

26. #tahoedreamin18

27. #tahoedreamin18
Development
Lifecycle
◇ Create development environments.
◇ Develop using Salesforce Web and local tools.
◇ Create testing environments, including UAT and integration.
◇ Migrate changes from development environment to integration environment.
◇ Test.
◇ Migrate changes from integration environment to UAT environment.
◇ Perform user-acceptance tests.
◇ Migrate changes from UAT environment to staging environment.
◇ Replicate production changes in staging environment.
◇ Schedule the release.

28. #tahoedreamin18
Before you start
◇ Run all local unit tests to verify that your development
environment is clean.
In case of failures:
◇ Take notes of what failed and why
◇ Address the resolution of all failing tests with the client /
developers / your team

29. #tahoedreamin18
Execution Order
◇ Triggers run before almost all declarative tools
◇ Workflows fire triggers once again (and just once)
◇ Processes and flows run almost at the end of the operation (but
can and will fire triggers, again
◇ Emails sending happens after finally committing the record to the
database
◇ Time based logic will re-evaluated at the time of execution

30. #tahoedreamin18
Using entry criteria
Entry criteria
◇ should filter and reduce so that logic is only executed for relevant record
◇ validate all required data
Some friends to remember
◇ ISCHANGED(), PRIORVALUE() functions
◇ “changed to subsequently meet criteria” setting for workflow rules
◇ recursive execution option for process builder

31. #tahoedreamin18
Using null checks
◇ absolutely required if you are using data from related records
◇ always check use ISBLANK() or ISNULL() before your access a related record)
and to avoid unintended copying of blank values

32. #tahoedreamin18
Opportunity
Using related
records
Account
SOQL Query
Opportunity
Line Items
SOQL Query
DML

33. #tahoedreamin18
Using related records
◇ Pulling in data from relating records in process builder consumes 1 SOQL query
and SOQL rows
◇ Updating related records consumes 1 DML statement and DML rows
◇ Updating related records fires triggers and declarative logic on the related object
- the context is getting bigger
◇ Flow and process builder are “bulkified by design”, but you have to help

34. #tahoedreamin18
Using no-code futures
A “future” call is simple way to tell code: Do that later outside of my current context.
◇ own resources & limit
◇ but no context of the current operation (e.g. PRIORVALUE() / Trigger.old)
If you invoke a process or flow from process builder, that essential works like a future
call (just without code)

35. #tahoedreamin18
The record couldn‘t be saved because
it failed to trigger a flow.
A flow trigger failed to execute
the flow with version ID
301b0000000g2s6.
When it breaks...

36. #tahoedreamin18
An error occurred at element
myRule_4_A2 (FlowRecordUpdate).
Too many SOQL queries: 101

37. #tahoedreamin18
When it breaks...
◇ Browser extensions like Salesforce Inspector help you find the flow by Id
◇ Developer Console “Analysis Perspective” helps you inspect the logic and
shows limit consumption

38. #tahoedreamin18
Debugging for No-Coders
◇ Read all messages carefully to identify IDs, component names
and possible error reasons.
◇ Use chatter, email, or platform events to publish steps into groups
/ emails / channels, or to the record’s feed
◇ Use the fault handler in Flow

39. #tahoedreamin18
It works!
Let‘s deploy

40. #tahoedreamin18
No
Well...

41. #tahoedreamin18
There‘s stuff to do
◇ Documentation.
It‘s part of building. Seriously.
◇ Test it
And by testing, we mean testing. Thorough testing.
◇ Review it
In pairs or teams. You can‘t review your own work. Seriously
(again)
◇ Deploy now you can, young padawan.

42. #tahoedreamin18
Documentation
◇ Overall rationale of the development
◇ Flow charts / Description of the logic
◇ Components
Did you think of
◇ Deployment Steps
◇ Consistently name all components
◇ Consistently fill description fields
◇ Add meaningful help texts

43. #tahoedreamin18
Test

44. #tahoedreamin18
Manual Testing
Run tests
Apex Unit Tests
Bulk Test

45. #tahoedreamin18
Manual Testing
◇ Does the logic work as described?
◇ Are all acceptance criteria satisfied?
◇ Does the logic affect you when you’re doing unrelated things?
◇ Can you create conditions that cause your logic to break?
◇ Test bad data, missing data, entry criteria too (negative testing
patterns)

46. #tahoedreamin18
Apex Unit Test
◇ Run all local unit tests to verify that all tests still complete
◇ Did you break something

47. #tahoedreamin18
Bulk Testing
◇ Keep (or create) CSV files for meaningful bulk tests
◇ Test all database operations (insert, update, delete, undelete)
◇ Verify results vs. your expectations
◇ Check logs for errors

48. #tahoedreamin18
User Acceptance Tests
◇ Let key users test drive your development
◇ Ask them do routine work
◇ Ask them to solve the problem they were thinking of when giving
their “user stories”

49. #tahoedreamin18
Deploy

50. #tahoedreamin18
Towards
Deployment
◇ Make and communicate a release plan
◇ Train your users
◇ Prepare your deployment (Documentation & Bundle)
◇ Backup Data
◇ Create a fresh Sandbox as a Metadata Backup
◇ Dry run (if needed)

51. #tahoedreamin18
Release Planning
◇ Use off-peak hours and days
◇ Communication is key
◇ No surprises
◇ Allow people
◇ No pre-weekend, pre-holidays, last-hour-of-the-day exercises

52. #tahoedreamin18
Training
◇ Realistic scenarios that users can relate to - in a sandbox
◇ Consider pre-built datasets and ETL or using DX to create
environments
◇ Again: Documentation and Communication is key
◇ Chatter group & Files / Libraries for end user documentation and
training (recorded sessions, manuals, cheat sheets etc.)

53. #tahoedreamin18
Deployment
Documentation
◇ Step-Number and/or Order of Steps
◇ Manual PRE-deployment tasks
◇ Deployment tasks
◇ Components (Metadata Type, Object, Name/Label, API-Name)
◇ Manual POST-deployment tasks

54. #tahoedreamin18
Backup
◇ Create a fresh Sandbox off Production as a metadata backup
◇ Use your favorite ETL tool for a data backup
◇ Prepare your deployment bundle in the backup sandbox to
overwrite your changes in case you need to roll back your
changes (“negative changeset strategy”)

55. #tahoedreamin18
Dry Run
◇ Create a fresh Sandbox off Production as a dummy target
◇ Send your changeset and walk through your deployment
document

56. #tahoedreamin18
Deploy
◇ There are limits to Metadata types that can be deployed
◇ Changeset deployments through a deployment path are tedious
and prone to errors like missing components etc.
◇ Browser extensions can support the process
◇ Metadata API is the preferable way
◇ Lots of free tools (DX and Ant Tool) and paid ones (Gearset,
AutoRabit, Flosum, Copado)

57. #tahoedreamin18
Finishing Up
◇ If you had processes and flows in your deployment, make sure
they are activated (these components are deployed in Inactive
state)
◇ If you did activate something - run local Apex tests again (you
won’t see damage earlier…)

58. #tahoedreamin18
Trailhead
◇ Deployment tools:
https://trailhead.salesforce.com/modules/alm_deployment/units/alm_tools
◇ Efficient Deployments:
https://trailhead.salesforce.com/modules/alm_deployment/units/alm_migrate_testing
◇ Plan Your Deployment:
https://trailhead.salesforce.com/modules/alm_deployment/units/alm_deploy
◇ Application Lifecycle Management Basics:
https://trailhead.salesforce.com/modules/alm_deployment/
units/alm_intro
◇ Learn More About Sandboxes:
https://trailhead.salesforce.com/modules/alm_deployment/units/
alm_sandbox

59. #tahoedreamin18
Resources
● Process Limits:
https://help.salesforce.com/articleView?id=process_limits.htm&type=5
● Order of Execution: https://developer.salesforce.com/docs/atlas.en-
us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm
● Deploying Flows
https://help.salesforce.com/articleView?id=process_changesets_packaging.htm&
type=5

60. #tahoedreamin18
Thanks!
Q&A - Any questions?
Connect with us:
◇ @meighanSF | meighanrockssf@gmail.com
◇ @stangomat | daniel.stange@die-interaktiven.de
◇ Slides at http://bit.ly/untilitbreaks

61. #tahoedreamin18
Addendum
● BlueCanvas.io can really do metadata backup. They emailed me on my
remark in the session. Check https://bluecanvas.io/2017/04/18/salesforce-
disaster-recovery.html
● Automated testing: Provar is a full scale solution. Coders should consider
including Nightwatch JS in their build scripts
● If you feel comfortable with the command line, you have to try out the
Salesforce CLI that comes with the Salesforce DX installation
● https://developer.salesforce.com/docs/atlas.en-
us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm

62. #tahoedreamin18
Blogpost to come
● http://blog.danielstange.de/2018/01/20/tahoedreamin18/