Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tahoe Dreamin 2018: It simply works... until it breaks!


Published on

Presentation held by Meighan Brodkey and Daniel Stange at Tahoe Dreamin', Jan 19, 2018
Salesforce empowers non-programmers to become App Builders and declarative developers in ways that administrators could only dream of before Visual Workflow and Process Builder had been introduced. With great powers comes great responsibility, and just because you actually could click a sweet process straight in production doesn’t mean that you should do so. Meighan and Daniel are going to present patterns for building your apps not just faster, but also better, more sustainable, and more robust.

Published in: Software
  • Be the first to comment

Tahoe Dreamin 2018: It simply works... until it breaks!

  1. 1. #tahoedreamin18 It simply works... until it breaks
  2. 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. 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. 4. #tahoedreamin18 And we don‘t mean common Salesforce developer patterns...
  5. 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. 6. #tahoedreamin18 Every developer can do better... Including you, no-code jedi!
  7. 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. 8. #tahoedreamin18 Great Patterns ◇ Change Management ◇ Documentation ◇ Consistency ◇ Simplicity ◇ Scalability ◇ Test-Driven
  9. 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. 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. 11. #tahoedreamin18 Consistency ◇ Naming Conventions ◇ Data Modeling ◇ Layouts ◇ Establish Paradigms that your users can learn and recognize
  12. 12. #tahoedreamin18 Simplicity ◇ Choose simple and performant solutions ◇ Prefer accessible solutions ◇ Avoid monoliths - break down complex logic
  13. 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. 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. 15. #tahoedreamin18 Design
  16. 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) / gliffy / LucidCharts
  17. 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. 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. 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. 20. #tahoedreamin18 Plan for Scale Make sure everything can handle at least 200 records at a time.
  21. 21. #tahoedreamin18 Be specific Use specific Entry Conditions for Automations to reduce workload and “false positives”
  22. 22. #tahoedreamin18 No Apex, No Limits? Declarative tools consume governor limits and are subject to platform restrictions
  23. 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. 24. #tahoedreamin18 Build
  25. 25. #tahoedreamin18 You need a sandbox NO EXCUSES
  26. 26. #tahoedreamin18
  27. 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. 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. 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. 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. 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. 32. #tahoedreamin18 Opportunity Using related records Account SOQL Query Opportunity Line Items SOQL Query DML
  33. 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. 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. 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. 36. #tahoedreamin18 An error occurred at element myRule_4_A2 (FlowRecordUpdate). Too many SOQL queries: 101
  37. 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. 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. 39. #tahoedreamin18 It works! Let‘s deploy
  40. 40. #tahoedreamin18 No Well...
  41. 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. 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. 43. #tahoedreamin18 Test
  44. 44. #tahoedreamin18 Manual Testing Run tests Apex Unit Tests Bulk Test
  45. 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. 46. #tahoedreamin18 Apex Unit Test ◇ Run all local unit tests to verify that all tests still complete ◇ Did you break something
  47. 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. 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. 49. #tahoedreamin18 Deploy
  50. 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. 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. 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. 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. 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. 55. #tahoedreamin18 Dry Run ◇ Create a fresh Sandbox off Production as a dummy target ◇ Send your changeset and walk through your deployment document
  56. 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. 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. 58. #tahoedreamin18 Trailhead ◇ Deployment tools: ◇ Efficient Deployments: ◇ Plan Your Deployment: ◇ Application Lifecycle Management Basics: units/alm_intro ◇ Learn More About Sandboxes: alm_sandbox
  59. 59. #tahoedreamin18 Resources ● Process Limits: ● Order of Execution: us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm ● Deploying Flows type=5
  60. 60. #tahoedreamin18 Thanks! Q&A - Any questions? Connect with us: ◇ @meighanSF | ◇ @stangomat | ◇ Slides at
  61. 61. #tahoedreamin18 Addendum ● can really do metadata backup. They emailed me on my remark in the session. Check 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 ● us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm
  62. 62. #tahoedreamin18 Blogpost to come ●