Designing salesforce solutions for reuse - Josh Dennis
0 likes395 views
The document provides an agenda for a Salesforce webinar on designing reusable Lightning Web Components (LWCs). It discusses identifying common functional patterns in requirements, designing generic and configurable LWCs, leveraging declarative tools for reusability, and community resources. The webinar aims to help participants think of their CRM as a product and reduce complexity by developing functionality that can be reused across objects and processes.
![Common configurable attributes
● Targets - where should the component be placed?
● Titles & Icons
● How to query for records to display (if showing a record’s child records)
○ Admin provides an entire SOQL?
○ Admin provides parts of a SOQL:
■ SELECT [insert fields here]
■ FROM [insert object here]
■ WHERE [insert relationship here] = :recordId [AND …]
■ ORDER BY [insert order field here] [ASC/DESC]
● UI-specific - e.g. colours to use, labels,
● Record Id (for Screen Flows)](https://image.slidesharecdn.com/designingsalesforcesolutionsforreuse-210826221849/85/Designing-salesforce-solutions-for-reuse-Josh-Dennis-15-320.jpg)
Designing salesforce solutions for reuse - Josh Dennis
- 1. Agenda: Housekeeping - Sakthivel Madesh: ● Introductions & Group overview Today’s content - Josh Dennis: ● Thinking about your CRM as a product ● Identifying functional patterns in requirements ● An approach for designing generic/reusable LWCs ● Community resources ● Reusability for declarative tools ● Closing thoughts Finishing up - Sakthivel Madesh: ● Salesforce Certification Voucher/Swags to random participants, please be stay til end.. -:)
- 2. Josh Dennis ● Passionate about reducing complexity and using platform strengths ● Have played many roles in the past: ○ Functional lead/BA ○ Proxy product owner ○ Solution design & architecture Salesforce Functional Lead @ Deloitte Digital, Sydney 14x certified https://www.linkedin.com/in/josh-dennis
- 3. Your CRM is a product! I’m not an ISV, why are you talking about building a product? ● Why has Salesforce been purchased in the first place? ○ Deliver fantastic experiences to customers ○ Manage e2e sales, support etc. processes ○ Quickly develop and deploy functionality on a low-code platform ● CRM product owners ultimately aim to deliver value to the business via the identification, prioritisation, and delivery of valuable CRM functionality. ● For each product backlog item, a PO should ask themselves & their teams ‘how can I use the strengths of this product to deliver the best possible functionality to our users?’
- 4. How can we - as developers - shift from developing purely to enable business productivity, to developing to also enable admin productivity?
- 5. Identifying functional patterns in requirements ● Use card sorting to group requirements into common functional Salesforce categories/subcategories ● Prepare a capability map for the functionality in scope (taken from https://www.radnip.com/the-salesforce-capability-map/)
- 6. Identifying functional patterns in requirements ● Apply MECE principles to determine the functionalities that underpin your requirements ● For each category/subcategory, consider: ○ Have WE already delivered it? ○ Is there a SF product that we could use to deliver this? ○ Is there an AppExchange product we could use to deliver this? ○ Is this a problem that may have been solved in another enterprise system?
- 7. Identifying functional patterns in requirements The scope of ABC Bank’s CRM definition project is to support the following business processes: ● ... ● Onboarding new customers ● Handle ad hoc customer support calls & external complaints ● ...
- 8. Identifying functional patterns in requirements Functionality Onboard customers Customer support & complaints ... Lead qualification & KYC checks ✔️ Record assignment & work management ✔️ ✔️ Customer deduplication ✔️ SLAs ✔️ Call scripting ✔️ ✔️ Product suggestion ✔️ Inbound communication (web, email, phone) ✔️ ✔️ Outbound communication (emails, SMS) ✔️ ✔️ Document generation ✔️ ✔️
- 9. Identifying functional patterns in requirements Functionality Onboard customers Customer support & complaints ... Lead qualification & KYC checks ✔️ Record assignment & work management ✔️ ✔️ Customer deduplication ✔️ SLAs ✔️ Call scripting ✔️ ✔️ Product suggestion ✔️ Inbound communication (web, email, phone) ✔️ ✔️ Outbound communication (emails, SMS) ✔️ ✔️ Document generation ✔️ ✔️
- 10. Where to from here? ● Solution the requirement - given we know how important it is & where it is likely to be used, how should we bring it to life? ○ OOTB/AppExchange? ○ Configuration? ○ Custom development? ● Documentation strategy: you have identified common/repeatable solutions, how do we document the solution (especially for our maintainers)?
- 13. UI Design - low fidelity ● Create a low fidelity wireframe ● Get input from your stakeholders: product owner/users and admins! ● Begin to determine what can be configurable (& what is needed to easily support that)
- 14. UI Design - high fidelity ● Convert the low fidelity wireframe into basic LWC with hardcoded values ● Break it into clear components & identify what data should be queried/returned by your Apex/LDS logic
- 15. Common configurable attributes ● Targets - where should the component be placed? ● Titles & Icons ● How to query for records to display (if showing a record’s child records) ○ Admin provides an entire SOQL? ○ Admin provides parts of a SOQL: ■ SELECT [insert fields here] ■ FROM [insert object here] ■ WHERE [insert relationship here] = :recordId [AND …] ■ ORDER BY [insert order field here] [ASC/DESC] ● UI-specific - e.g. colours to use, labels, ● Record Id (for Screen Flows)
- 16. Enabling admin configuration Lightning App Builder Config Config variables defined in LWC meta.xml file CMDT CMDT primarily, minimal config variables in LWC meta.xml Lightning App Builder JSON JSON string in Lightning App Builder Lightning App Builder w/ CPE Develop a Custom Property Editor to simply configuration
- 17. Apex considerations for generic LWCs ● What parameters are you passing in from the LWC? ○ recordId ○ Configurable attributes from Lightning App Builder? ● Define the data you’re returning from the controller: a wrapper class or standard output of SOQL (etc.) statement? ● ‘Get metadata’: if using CMDT, querying for configuration ● ‘Get records’: pass in component pieces of SOQL, run/return a SOQL ● Be wary, Service Cloud objects don’t have a ‘Name’ field!
- 18. Apex or LDS for field-level data? ● Apex has worked more consistently for me. ○ Manually control cache with refreshApex() and getRecordNotifyChange() ○ Imperatively calling methods seems to give most flexibility ● LDS appears to be more performant & has a lot of base functionality, but also does not appear to support dynamically defined queries as well.
- 19. Resources in the community: UnofficialSF See https://unofficialsf.com/flow-screen-components/
- 20. Resources in the community: Nebula Logger See https://github.com/jongpie/NebulaLogger
- 21. Resources in the community: SF Labs ● CMDT Enhanced Related List ● Time Warp ● Lightning Web Chart.js Component ● ..and more!
- 22. Worked example: object-agnostic flows ● Flows don’t need to be specific to one type of object or process ● Find opportunities to create ‘helper’ or ‘utility’ flows that you can use in many places: ○ Use the same screen flow across multiple objects ‘seamlessly’ ○ Create a Log record every time an exception occurs ○ Centrally manage notification orchestration across all mediums (e.g. email, SMS) ● Consider external services - especially if you already use Mulesoft!
- 23. Worked example: object-agnostic flows ● Flows don’t need to be specific to one type of object or process ● Find opportunities to create ‘helper’ or ‘utility’ flows that you can use in many places: ○ Use the same screen flow across multiple objects ‘seamlessly’ ○ Create a Log record every time an exception occurs ○ Centrally manage notification orchestration across all mediums (e.g. email, SMS) ● Consider external services - especially if you already use Mulesoft!
- 24. Closing thoughts & questions ● How well do you know your admins and product owners? ● How process/object-agnostic can you make your next development item? ● What opportunities to refactor/simplify your org can you identify?