CINXE.COM
Intentional | Salesforce Architects
<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title> Intentional | Salesforce Architects</title> <!-- One Trust --> <script async type="text/javascript" src="https://a.sfdcstatic.com/digital/one-trust/core/stable/scripttemplates/otSDKStub.js" data-domain-script="8e783e8c-0ad0-475d-8fca-4a03afa0a02a" crossorigin ></script> <!-- Data Cloud Manager --> <script type="text/javascript" src="https://cdn.c360a.salesforce.com/beacon/c360a/1264deb6-4cc0-4a48-b265-ce707a286cfd/scripts/c360a.min.js" defer></script> <!-- Google Tag Manager --> <script> (function (w, d, s, l, i) { w[l] = w[l] || []; w[l].push({'gtm.start': new Date().getTime(), event: 'gtm.js'}); var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : ''; j.async = true; j.src = 'https://www.googletagmanager.com/gtm.js?id=' + i + dl; f .parentNode .insertBefore(j, f); })(window, document, 'script', 'dataLayer', 'GTM-MPDHG6B'); </script> <!-- End Google Tag Manager --> <link rel="apple-touch-icon" sizes="180x180" href="/1/asset/immutable/s/17380066300000000/assets/images/favicons/apple-touch-icon.png"> <link rel="icon" type="image/png" sizes="32x32" href="/1/asset/immutable/s/17380066300000000/assets/images/favicons/favicon-32x32.png"> <link rel="icon" type="image/png" sizes="16x16" href="/1/asset/immutable/s/17380066300000000/assets/images/favicons/favicon-16x16.png"> <link rel="manifest" href="/1/asset/immutable/s/17380066300000000/assets/site.webmanifest" crossorigin="use-credentials"> <link rel="mask-icon" href="/1/asset/immutable/s/17380066300000000/assets/images/favicons/safari-pinned-tab.svg" color="#5bbad5"> <link rel="shortcut icon" href="/1/asset/immutable/s/17380066300000000/assets/images/favicons/favicon.ico"> <link rel="canonical" href="https://architect.salesforce.com/well-architected/easy/intentional"/> <meta name="google-site-verification" content="9nBLHedRs97kceoTtOMsUGrVIhNfsJHbExzaKVARgAM"> <meta name="google-site-verification" content="GiaTqJgaiTF7nPD6gVxphfKcgFK9leNVs5Wp4mpqoGc"/> <meta name="msapplication-TileColor" content="#da532c"> <meta name="msapplication-config" content="/assets/browserconfig.xml"> <meta name="theme-color" content="#ffffff"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta property="og:url" content="https://architect.salesforce.com/well-architected/easy/intentional"> <meta property="og:type" content="website"> <meta name="author" content="Salesforce Architects"> <meta name="title" property="og:title" content="Salesforce Architects | Intentional"> <meta name="description" property="og:description" content="Create Salesforce solutions to drive business value today and tomorrow."> <meta name="image" property="og:image" content="https://architect.salesforce.com/assets/images/cards/intentional.png"> <meta property="og:image:url" content="https://architect.salesforce.com/assets/images/cards/intentional.png"> <meta name="twitter:image" content="https://architect.salesforce.com/assets/images/cards/intentional.png"> <meta name="twitter:card" content="summary_large_image"> <meta name="twitter:site" content="@SalesforceArchs"> </script> <link rel="preload" href="/1/asset/immutable/s/17380066300000000/assets/css/styles.css" as="style"> <link rel="stylesheet" href="/1/asset/immutable/s/17380066300000000/assets/css/styles.css"> <link rel="preload" href="/1/asset/immutable/s/17380066300000000/assets/dx/css/index.css" as="style"> <link rel="stylesheet" href="/1/asset/immutable/s/17380066300000000/assets/dx/css/index.css"> <style> .preview { width: 100%; display: flex; align-items: center; justify-content: center; background-image: linear-gradient(45deg,rgba(0,0,0,.025) 25%,transparent 0,transparent 50%,rgba(0,0,0,.025) 0,rgba(0,0,0,.025) 75%,transparent 0,transparent); background-size: 64px 64px; color: #102c62; background-color: rgb(234, 245, 254); padding: 8px; box-sizing: border-box; } .preview a:active, .preview a:hover, .preview a:link, .preview a:visited { color: #0071D1; } .preview > span { padding: 0 6px; } </style> </head> <body> <header> <tds-header config="{"logo":{"assistiveText":"Salesforce Architects logo","link":{"href":"/"},"url":"/assets/images/architects_logo_vertical.svg"},"logoMobile":{"assistiveText":"Salesforce Architects logo","link":{"href":"/"},"url":"/assets/images/architects_logo_vertical.svg"},"header":[{"label":"Home","link":{"href":"/","target":null},"active":true},{"label":"Well-Architected","sections":[{"label":"Build trusted, easy and adaptable solutions","items":[{"label":"Well-Architected Overview","link":{"href":"/well-architected/overview","target":null},"iconUrl":"/assets/images/nav/overview-icon.svg","description":"Build healthy solutions"},{"label":"Trusted","link":{"href":"/well-architected/trusted/overview","target":null},"iconUrl":"/assets/images/nav/trusted-icon.svg","description":"Protect your business and stakeholders"},{"label":"Easy","link":{"href":"/well-architected/easy/overview","target":null},"iconUrl":"/assets/images/nav/easy-icon.svg","description":"Deliver value fast"},{"label":"Adaptable","link":{"href":"/well-architected/adaptable/overview","target":null},"iconUrl":"/assets/images/nav/adaptable-icon.svg","description":"Evolve with your business"}]},{"label":"Well-Architected Tools","items":[{"label":"Pattern & Anti-Pattern Explorer","link":{"href":"/well-architected/explorer","target":null},"iconUrl":"/assets/images/nav/roadmap-explorer.svg","description":"Create lists of patterns or anti-patterns"}]}]},{"label":"Diagrams","sections":[{"label":"Create and find artifacts for your solutions","items":[{"label":"Salesforce Diagrams Overview","link":{"href":"/diagrams/#framework","target":null},"iconUrl":"/assets/images/nav/salesforce-diagram-framework.svg","description":"Learn how to create effective diagrams"},{"label":"Reference Architecture Gallery","link":{"href":"/diagrams/#reference-architecture-gallery","target":null},"iconUrl":"/assets/images/nav/template-gallery.svg","description":"Pre-built artifacts to get started fast"},{"label":"Data Model Gallery","link":{"href":"/diagrams/#data-model-gallery","target":null},"iconUrl":"/assets/images/nav/design-patterns.svg","description":"Product entity relationship diagrams"}]}]},{"label":"Decision Guides","sections":[{"label":"Choose the right Salesforce tools","items":[{"label":"Asynchronous Processing","link":{"href":"/decision-guides/async-processing","target":null},"iconUrl":"/assets/images/Asynchronous-Processing-Decision-Guide.svg","description":"Architect's Guide to Asynchronous Processing with Salesforce"},{"label":"Event-Driven Architecture","link":{"href":"/decision-guides/event-driven","target":null},"iconUrl":"/assets/images/nav/event-driven-architecture.svg","description":"Architect's Guide to Event-Driven Architecture with Salesforce"},{"label":"Data Integration","link":{"href":"/decision-guides/data-integration","target":null},"iconUrl":"/assets/images/nav/data-integration.svg","description":"Architect's Guide to Data Integration with Salesforce"},{"label":"Record-Triggered Automation","link":{"href":"/decision-guides/trigger-automation","target":null},"iconUrl":"/assets/images/nav/record-triggered-automation.svg","description":"Architect's Guide to Record-Triggered Automation on Salesforce"},{"label":"Building Forms","link":{"href":"/decision-guides/build-forms","target":null},"iconUrl":"/assets/images/nav/building-forms.svg","description":"Architect's Guide to Building Forms on Salesforce"},{"label":"See All Guides","link":{"href":"/decision-guides","target":null},"iconUrl":"/assets/images/nav/decision-guides.svg"}]}]},{"label":"Fundamentals","sections":[{"label":"Know the basics of Salesforce architecture","items":[{"label":"The Salesforce Platform - Transformed for Tomorrow","link":{"href":"/fundamentals/platform-transformation","target":null},"iconUrl":"/assets/images/nav/next-gen-salesforce-platform.svg","description":"Learn about the latest Salesforce Platform innovations"},{"label":"Architecture Basics","link":{"href":"/fundamentals/architecture-basics","target":null},"iconUrl":"/assets/images/nav/architecture-basics.svg","description":"Learn basics of architecting with Salesforce"},{"label":"Platform Multitenant Architecture","link":{"href":"/fundamentals/platform-multitenant-architecture","target":null},"iconUrl":"/assets/images/nav/platform-mulitenant-architecture.svg","description":"Learn about the architecture of Salesforce Customer 360 Platform"},{"label":"Platform Sharing Architecture","link":{"href":"/fundamentals/platform-sharing-architecture","target":null},"iconUrl":"/assets/images/nav/sharing-guide.svg","description":"Learn how to provide secure data access"},{"label":"See All Fundamentals","link":{"href":"/fundamentals","target":null},"iconUrl":"/assets/images/nav/decision-guides.svg"}]}]},{"label":"Resources","sections":[{"label":"Project Resource Gallery","items":[{"label":"Artificial Intelligence","link":{"href":"/resources/project-resource-gallery/ai","target":null},"iconUrl":"/assets/images/nav/template-gallery.svg","description":"Get AI projects started fast"}]},{"label":"Releases","items":[{"label":"Release Overviews","link":{"href":"/releases","target":null},"iconUrl":"/assets/images/nav/releases.svg","description":"Explore what's changed across releases"}]},{"label":"Roadmap Explorer","items":[{"label":"Roadmap Explorer","link":{"href":"/roadmaps/roadmap-explorer","target":null},"iconUrl":"/assets/images/nav/roadmap-explorer.svg","description":"Plan in alignment with Salesforce innovation"}]}]},{"label":"Connect","sections":[{"label":"Connect with Salesforce Architects","items":[{"label":"Our Blog","link":{"href":"/connect/blog","target":null},"iconUrl":"/assets/images/architects_logo_vertical.svg","description":"A tech publication for architects"},{"label":"Our Youtube Channel","link":{"href":"https://www.youtube.com/c/SalesforceArchitects","target":"_blank","rel":"noopener"},"iconUrl":"/assets/images/nav-youtube.png","description":"Videos to empower and inspire architects"},{"label":"Trailblazer Community","link":{"href":"https://trailblazer.salesforce.com/about","target":"_blank","rel":"noopener"},"iconUrl":"/assets/images/nav-community-groups.png","description":"Get help, answers, and inspiration from peers"}]},{"label":"Stay up to date with our feeds","items":[{"label":"Our Website Feed","link":{"href":"https://architect.salesforce.com/feed.xml","target":null},"iconUrl":"/assets/icons/rss.png","description":"Get new diagrams and content updates"},{"label":"Our Blog Feed","link":{"href":"https://medium.com/feed/salesforce-architects","target":"noopener"},"iconUrl":"/assets/icons/rss-black.png","description":"Our latest blogs delivered"},{"label":"Our Youtube Channel Feed","link":{"href":"https://www.youtube.com/feeds/videos.xml?channel_id=UC9OaSDoddWJ7Zwu83nANsCA","target":"_blank","rel":"noopener"},"iconUrl":"/assets/icons/rss-red.png","description":"Subscribe for video updates"}]}]}],"footer":{"columns":[{"heading":"Well-Architected","links":[{"href":"/well-architected/overview","label":"Overview"},{"href":"/well-architected/trusted/overview","label":"Trusted"},{"href":"/well-architected/easy/overview","label":"Easy"},{"href":"/well-architected/adaptable/overview","label":"Adaptable"},{"href":"/well-architected/explorer","label":"Pattern & Anti-Pattern Explorer"}]},{"heading":"Diagrams","links":[{"href":"/diagrams/#framework","label":"Salesforce Diagrams Overview"},{"href":"/diagrams/#reference-architecture-gallery","label":"Reference Architecture Gallery"},{"href":"/diagrams/#data-model-gallery","label":"Data Model Gallery"}]},{"heading":"Decision Guides","links":[{"href":"/decision-guides/event-driven","label":"Event-Driven Architectures"},{"href":"/decision-guides/data-integration","label":"Data Integration"},{"href":"/decision-guides/trigger-automation","label":"Record-Triggered Automation"},{"href":"/decision-guides/build-forms","label":"Building Forms"},{"href":"/decision-guides","label":"See All Guides"}]},{"heading":"Fundamentals","links":[{"href":"/fundamentals/platform-transformation","label":"Platform Transformation"},{"href":"/fundamentals/architecture-basics","label":"Architecture Basics"},{"href":"/fundamentals/platform-multitenant-architecture","label":"Platform Multitenant Architecture"},{"href":"/fundamentals/platform-sharing-architecture","label":"Plaform Sharing Architecture"}]},{"heading":"Resources","links":[{"href":"/resources/project-resource-gallery/ai","label":"Project Resource Gallery"},{"href":"/roadmaps/roadmap-explorer","label":"Roadmap Explorer"},{"href":"/releases","label":"Release Overviews"}]},{"heading":"Connect","links":[{"href":"/connect/blog","label":"Our Blog"},{"href":"https://www.youtube.com/c/SalesforceArchitects","label":"Our Youtube Channel"},{"href":"https://trailblazer.salesforce.com/about","label":"Trailblazer Community"}]}],"global":{"logo":{"assistiveText":"Salesforce Logo","url":"/assets/images/salesforce-corp-logo.jpg"},"copyrightTitle":"© Copyright 2024 Salesforce, Inc. ","copyrightEnd":" Various trademarks held by their respective owners. Salesforce, Inc. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States","links":[{"href":"https://www.salesforce.com/company/legal/","label":"Legal","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/legal/sfdc-website-terms-of-service/","label":"Terms of Service","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/legal/privacy/","label":"Privacy Information","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/disclosure/","label":"Responsible Disclosure","target":"_blank","rel":"noopener"},{"href":"https://trust.salesforce.com/","label":"Trust","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/contact-us/?d=cta-glob-footer-11","label":"Contact","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/form/other/privacy-request/","label":"Your Privacy Choices","target":"_blank","rel":"noopener","icon":"/assets/images/privacyicon.png"}]}}}"> <tds-search slot="search"></tds-search> </tds-header> </header> <div class="guide"> <tm-page-header-a title="Intentional" jptranslation="https://sf-archs.cdn.salesforce-experience.com/cms/delivery/media/MCUS2KCQSLY5CKRPUCW2PYTHP4AU?version=2.1&channelId=0apHs000000y0QG&oid=00DHs000003Wrxy" url="/well-architected/easy/intentional"></tm-page-header-a> <tm-content reading-time="25" last-updated="July 2024" image-hash="wmm2l"> <blockquote> <p>Read about our update schedules <a href="../contributors">here</a>.</p> </blockquote> <h2 id="introduction">Introduction</h2> <p>Intentional solutions deliver business value immediately and over time. Intentional architectures are planned and delivered strategically, can be maintained effectively, and are easy for humans to read and understand.</p> <p>Features and fixes are prioritized and delivered in ways that are transparent to business and technology stakeholders alike. Engineering choices create implementations that are easy for delivery and maintenance teams to work with, without added features or complications. Intentional architectures are easier to own, maintain, and evolve with the business because they follow clear and consistent implementation patterns. Builders can interpret and implement designs for new features, and maintenance teams can understand documentation of what’s been implemented.</p> <p>You can create more intentional systems by focusing on three key areas: strategy, maintainability, and readability.</p> <h2 id="strategy">Strategy</h2> <p>Strategy in architecture means systems are thoughtfully planned and delivered. It means delivery and maintenance teams have a clear view of the work to be done today and in the future, and everyone is aligned around the “why” of the work to be done. It means urgent requests can be triaged effectively and efficiently, and stakeholders can clearly understand the impacts and trade-offs of requests.</p> <p>You can build clearer strategy into your architecture by focusing on prioritzation, roadmapping and governance.</p> <h3 id="prioritization">Prioritization</h3> <p>Prioritization means planning the order and scope of the work you will deliver. Prioritization involves understanding the true impact of deliverables on the business, evaluating those impacts against other work requests and the overall roadmap for your product or program.</p> <p>One way to evaluate the impact of a given work item is to look at the actual cost or benefit to the business. Once you’ve identified the <a href="/../well-architected/easy/automated#KPIs">KPIs</a> for the automation, you can use a <a href="/../resources/kpi-spreadsheet-template">business impact calculation worksheet</a> to evaluate the overall cost or benefit of implementation. These calculations can help you get alignment and buy-in from your stakeholders about what automations to build and in what order. They can also help you identify automations to postpone or avoid. For automations, see <a href="/../well-architected/easy/automated#Process_Design">process design</a> for more about identifying effective work.</p> <p>Establishing a prioritization framework for delivery will also help you and your maintenance teams manage user expectations and stay aligned with your roadmap.</p> <p>Some considerations you can use for prioritization include:</p> <ul> <li>Business impact (cost/benefit) of the deliverable</li> <li>Amount of new work required for the deliverable</li> <li>Amount of work required to maintain the deliverable</li> </ul> <p>The list of <a href="/../well-architected/easy/intentional#Strategy_Patterns_and_Anti_Patterns">patterns and anti-patterns</a> below shows what proper (and poor) prioritization looks like when it comes to Salesforce work. You can use these to validate your implementation plans, or identify where you need to better identify priorities before you build.</p> <p>To learn more about tools available from Salesforce for help with prioritization, see <a href="/../well-architected/easy/intentional#Tools_Relevant_To_Intentional">Tools Relevant to Intentional</a>.</p> <h3 id="roadmapping">Roadmapping</h3> <p>A roadmap is a prioritized, validated, well-defined view of what's to be done. Effective roadmaps provide a clear picture of the business impact and technology impact of the work ahead. Engaging your business and technical stakeholders is a key part of roadmapping. Roadmaps enable you to get feedback and buy-in about the approach and outcomes before any work begins. Ultimately, roadmaps align every stakeholder about the “why” of work ahead.</p> <p>If your team uses a backlog, it's important to understand your roadmap is not a summary or list of the items in the backlog. The relationship is the opposite: Items are only to enter the backlog if they can be clearly and credibly tied to a deliverable on your roadmap. High-quality roadmaps, created with the engagement of stakeholders, provide delivery and maintenance teams with a clear view of what they should focus on and how they should prioritize requests, making it easier to sort out conflicting requests and manage stakeholder expectations.</p> <p>Poor or non-existent roadmapping leads to:</p> <ul> <li>Lack of clarity around when new features and functionality will be available</li> <li>Conflicting priorities among stakeholders</li> <li>A disconnect between the solutions being delivered and the overall organizational vision</li> <li>Difficulty understanding what work is underway</li> <li>Uneven workloads across teams</li> <li>Lack of visibility into relationships and dependencies between work items</li> <li>Stalled implementations, due to mismanaged dependencies</li> </ul> <p>Stakeholders often need information that aligns to their roles in order to make decisions. Creating effective roadmaps requires a clear understanding of your audience and the type of information they need. Roadmaps are categorized into two styles to support business and technical audiences. Each style contains two levels of granularity to support different types of information.</p> <p>Business roadmaps help stakeholders plan for organizational change, capitalize on growth opportunities, and stay aligned on corporate objectives. Business roadmaps also provide a way to ensure that IT spend aligns to the overall business vision.</p> <ul> <li>Create a business capability roadmap to show executive stakeholders the capabilities that will be enabled. This type of roadmap contains high-level details about the capabilities themselves and how they align to business objectives, such as increasing operational efficiencies or launching a new product line.</li> <li>Create a business feature roadmap to drill into a specific capability and show its supporting features and functionality when you need to help business stakeholders with resource planning, budgeting, and change management.</li> </ul> <p>Technology roadmaps help technical stakeholders with budget and resource allocation planning. They also help implementation teams understand where their projects fit as part of a bigger overall picture and identify any cross-team dependencies.</p> <ul> <li>Create a technology system roadmap to show the specific systems that will be implemented, along with any system-level dependencies. This type of roadmap shows high-level system information and the alignment between systems and business capabilities.</li> <li>Create a technology component roadmap to drill into the specific components of a system that will be deployed to help with resource planning and enablement requirements. This type of roadmap shows component-level information and implementation requirements (for example, declarative development, pro-code, and so on).</li> </ul> <p>Make sure your roadmaps contain realistic timelines. A common mistake is to include only the amount of time it will take to implement a system without also considering the amount of time it will take to complete related activities. This can result in over-allocation of implementation team members and longer than anticipated delays. When creating a roadmap, account for the time it will take to complete the following:</p> <ul> <li>Documentation of all new and updated functionality</li> <li>Maintenance of existing functionality needed to support new features</li> <li>Updates to related systems required to support integrations</li> <li>Elevated support from project teams immediately after go-live</li> <li>Testing, training, and change management</li> </ul> <p>Business and technology roadmaps that are well aligned communicate a holistic view of when capabilities will go live and what technology is behind them. The list of <a href="/../well-architected/easy/intentional#Strategy_Patterns_and_Anti_Patterns">patterns and anti-patterns</a> below shows what proper (and poor) roadmaps look like for a Salesforce org. You can use these to validate or improve your roadmapping strategy.</p> <p>To learn more about Salesforce tools that can help you with roadmapping, see <a href="/../well-architected/easy/intentional#Tools_Relevant_To_Intentional">Tools Relevant to Intentional</a>.</p> <h3 id="governance">Governance</h3> <p>Governance is the structure you use to handle prioritization, decision-making, and change management with your stakeholders. Governance makes it clear how decisions are made and communicated. It provides consistent ways for feedback and requests to enter into the decision-making process, and for all stakeholders to understand the status of maintenance and development work. Governance helps release management processes to be clear and consistent, and helps all team members understand their roles and responsibilities.</p> <p>Without proper governance, teams will experience a variety of issues, including:</p> <ul> <li>Requests for overlapping features and functionality arrive ad hoc</li> <li>Implementation teams prioritize "easier" efforts or requests from more influential stakeholders, without proper consideration of business value, trade-offs, or overall organizational goals</li> <li>Lack of consistent approval and review processes</li> <li>Inconsistent release cadences and quality</li> <li>High defect rates, overwrites, conflicts, and redundant work in development efforts</li> </ul> <p>Perhaps the clearest sign that a system doesn’t have effective governance is slow and cumbersome releases. It’s important to recognize that the size of a governance system is not a measure of its efficacy. In fact, elaborate systems for governance (like those found in many large enterprises) can throttle the speed and frequency of releases.</p> <p>Good governance is about making it hard for bad customizations to get past the early stages of development, and getting good customizations into production predictably and consistently.</p> <p>Too often, governance efforts are reactionary. They are initiated or redoubled when an issue, such as excessive technical debt, starts becoming a business problem. In many cases, the unfortunate response is for the business to “lock down” development efforts and releases, instead of creating effective <a href="/../resources/design-standards-template">design standards</a> and building automation to enforce those standards within developer tool chains and source control systems.</p> <p>When building the framework for your Salesforce governance system include the following elements and consider these key questions to be answered:</p> <ul> <li><strong>Work requests.</strong> How can users ask for functionality or features? How are bugs reported?</li> <li><strong>Prioritization and work planning.</strong> Who decides what work requests matter? How is work scoped, prioritized, and accepted or signed off on?</li> <li><strong>Environments and release planning.</strong> What is the environment pipeline for development, testing, and release? Who does what to provision, refresh, and provide access? Who handles deployments and validation? How and when are changes released? How do you handle deployments or environments during a Salesforce release cycle? (For more on this, see <a href="/../well-architected/adaptable/resilient#Application_Lifecycle_Management">Application Lifecycle Management</a>.)</li> <li><strong>Service ownership and production support.</strong> Who supports what? Who handles “hot-fix” production issues? How are those items tested and released? Who is responsible for the overall security standards of the org?</li> </ul> <p>The list of <a href="/../well-architected/easy/intentional#Strategy_Patterns_and_Anti_Patterns">patterns and anti-patterns</a> below shows what proper (and poor) governance looks like for a Salesforce org. You can use these to validate or improve your governance strategy.</p> <p>To learn more about Salesforce tools available for governance, see <a href="/../well-architected/easy/intentional#Tools_Relevant_To_Intentional">Tools Relevant to Intentional</a>.</p> <h3 id="strategy-patterns-and-anti-patterns">Strategy Patterns and Anti-Patterns</h3> <p>The following table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.</p> <p>✨ Discover more patterns for strategy in the <a href="/../well-architected/explorer?Easy=Strategy">Pattern & Anti-Pattern Explorer</a>.</p> <table> <colgroup> <col span="1" style="width: 10%;"> <col span="1" style="width: 45%;"> <col span="1" style="width: 45%;"> </colgroup> <tbody> <tr> <th scope="colgroup"></th> <th scope="colgroup">Patterns</th> <th scope="colgroup">Anti-Patterns</th> </tr> <tr> <td rowspan="2"><b>Prioritization</b></td> <td><b>Within your documentation:</b> <br> - All new work items have clear business value metrics (for example, revenue increases, cost savings from process optimizations, and so on) <br> - Roadmaps show work prioritized based on business value</td> <td><b>Within your documentation:</b> <br> - Business value associated with work is unclear or nonexistent <br> - Roadmaps don't exist</td> </tr> <tr> <td><b>Within your company:</b> <br> - Implementation and maintenance costs have been identified for all work items <br> - Requests for features are prioritized based on business impact, amount of new work required to deliver, and amount of work required to maintain</td> <td><b>Within your company:</b> <br> - Costs associated with implementing and maintaining features are unclear <br> - Requests are delivered on an ad hoc or first-in/first-out basis</td> </tr> <tr> <td rowspan="2"><b>Roadmapping</b></td> <td><b>Roadmaps:</b> <br> - Communicate information that's tailored to your audience (business or technical) <br> - Communicate information at the correct level of detail <br> - Show start and end dates <br> - Show prerequisites and dependencies</td> <td><b>Roadmaps (if they exist):</b> <br> - Are used as project kickoff materials and not artifacts for delivery <br> - Do not help align stakeholders and delivery teams <br> - Mix levels of detail (for example, by including systems and components within the same roadmap) <br> - Contain information that isn't tailored to their audience (for example, business capabilities and systems within the same roadmap)</td> </tr> <tr> <td><b>Within your business:</b> <br> - Stakeholders understand the "why" of work items <br> - Delivery teams know how to evaluate backlog items against longer term priorities <br> - Teams know who's doing what and how to manage dependencies <br> - Work is intentional, even when priorities have to change quickly</td> <td><b>Within your business:</b> <br> - Work is pulled from whatever is in the backlog and there is no clear “why" <br> - Teams have trouble coordinating interdependent work and often replicate work without realizing it <br> - Work is often reactive <br> - Stakeholders often feel frustrated and confused about what's being done and are usure when new capabilities will be delivered</td> </tr> <tr> <td><b>Governance</b></td> <td><b>Within your business:</b> <br> - Users can easily report bugs and request features <br> - The prioritization process for work items is documented and transparent to all stakeholders <br> - Environment strategy is clearly documented and development environments match the documentation <br> - Release planning is predictable and transparent to all delivery team members <br> - Team members know who's responsible for what throughout app lifecycle <br> - Releases are clear to users and delivery/maintenance teams <br> - Production support processes are clear and hot-fixes have a clear path to production <br> - Teams and projects only use AI models approved for business uses</td> <td><b>Within your business:</b> <br> - Bug reports and feature requests are ad hoc <br> - Work items have no clear prioritization <br> - Environments are provisioned ad hoc and may not be refreshed predictably; developers often do not have the environments and access they need <br> - Releases are unpredictable for delivery teams and users <br> - Teams do not know who is responsible for what <br> - Hot-fixes are addressed ad hoc <br> - Your backlog has become an “idea bank” that is stale and stagnant <br> - Governance bodies act as a help desk that troubleshoots support requests <br> - Documentation is not easily accessible <br> - Teams select AI models ad hoc</td> </tr> </tbody> </table> <h2 id="maintainability">Maintainability</h2> <p>Maintainability means a system can be kept in a healthy state, with new features moving into and technical debt moving out of the system on a regular, predictable basis. Maintainable systems enable your teams to deliver value to the business with predictable speed and quality. The maintainability of a system depends on several factors, including how readable it is, how loosely coupled it is, and how thorough its testing strategy is.</p> <p>Most importantly, the maintainability of a system depends on the straightforwardness of its design. This section covers ways to create more straightforward solution designs, and increase maintainability.</p> <p>You can build solutions that are easier to maintain by focusing on two keys: using standard over custom functionality and handling technical debt.</p> <h3 id="standard-versus-custom-functionality">Standard Versus Custom Functionality</h3> <p>Salesforce offers a range of prebuilt solutions — Sales Cloud, Service Cloud, and many Salesforce industry solutions — as well as the flexibility to create your own custom solutions. The foundational services that power Salesforce’s own cloud solutions are also available to any custom solutions built on the Salesforce Customer 360 Platform. Use the prebuilt services and solutions from Salesforce as a trusted foundation for as many of your solutions as possible.</p> <p>Using prebuilt platform services has two distinct benefits. First, your apps naturally benefit from the latest Salesforce innovations with every release. And second, your development teams can focus on expanding and deepening the business capabilities provided by your Salesforce solutions rather than handling basic architectural heavy lifting.</p> <p>Properly choosing when to use standard functionality and when to build custom functionality isn’t challenging from an architectural point of view. The keys are:</p> <ul> <li><strong>Customizing the platform means modifying and extending, not copying</strong>. As you design or evaluate your architecture, you should ask: Does this already exist somewhere in the Salesforce platform? If the answer is “<em>Yes, but...[insert changes a business stakeholder wants here...]”</em>, then use the prebuilt feature in the platform. The architectural work to be done is identifying the most useful ways to configure the prebuilt Salesforce feature to meet business expectations.</li> <li><strong>No customizations are trivial</strong>. Over time, every change has consequences. If you need to implement a custom solution, you can mitigate the inevitable <a href="/../well-architected/easy/intentional#Technical_Debt">technical debt</a> your system will accrue by choosing to use low-code technology whenever possible, and by creating <a href="/../well-architected/adaptable/composable">composable units</a> in your implementations.</li> <li><strong>Consider the build-buy spectrum</strong>. The <a href="https://www.salesforce.com/solutions/appexchange/overview/">Salesforce AppExchange</a> is a marketplace of apps and solutions to extend Salesforce. AppExchange apps can deliver functionality without the overhead involved in building and maintaining a custom solution. Consider the following when evaluating AppExchange solutions: <ul> <li>Identify solution features and gaps. Ideally, you’ll find an app that meets all of your business requirements. In reality, you may not find a perfect fit. As you assess solutions, map functionality in the potential solution to a prioritized list of business requirements. This will help you find the solution that best meets your most critical requirements.</li> <li>Use sandboxes and free trials. Use free trial periods to evaluate apps in sandbox environments and identify the best fit. Determine if apps will require you to make configuration changes that conflict with your existing configuration.</li> <li>Consider near-term and long-term costs. Evaluate long-term app maintenance savings against the recurring costs of subscription-based apps. Avoid scenarios where you have to pay recurring costs for lots of functionality your business stakeholders will never use.</li> </ul> </li> <li><strong>Use the prebuilt data models from Salesforce.</strong> Salesforce provides prebuilt data models for Sales, Service, and a variety of industry verticals. Using the data models provided by Salesforce ensures capabilities in your system are defined only once (eliminating redundancy and silos), establishes a single source of truth across the entire system, makes it easier to understand application data with analytics, makes it easier to use Salesforce’s prebuilt artificial intelligence services, lowers maintenance costs (by reducing customizations you need to support), and reduces technical debt.</li> </ul> <p>It is that simple. As you can see in the <a href="/../well-architected/easy/intentional#Maintainability_Patterns_and_Anti_Patterns">patterns and anti-patterns</a> below, the anti-patterns boil down to replicating standard features in a custom solution, or using more complex technology to deliver customizations.</p> <p>In practice, you may encounter a scenario in which a custom functionality anti-pattern is viewed by business stakeholders as the best or only viable way forward. In these instances, it is essential that you explain to the stakeholders the trade-offs involved in choosing this path and then thoroughly document the decision, its rationale, and its implementation. This is also an area where delivering core value early and adapting over time can help your stakeholders better understand the best way forward.</p> <p>To learn more about Salesforce tools that can help you increase maintainability, see <a href="/../well-architected/easy/intentional#Tools_Relevant_To_Intentional">Tools Relevant to Intentional</a>.</p> <h3 id="technical-debt">Technical Debt</h3> <p>Technical debt is a natural part of any system. Yesterday’s sound designs can become anti-patterns when technology or business needs change. Maybe something built to fill a gap in Salesforce platform functionality suddenly becomes redundant with a new Salesforce release or product launch. Perhaps a more performant or flexible technology supersedes a technology you’ve already implemented. Technical debt can be created in many ways.</p> <p>A key benefit of building applications with the Salesforce Customer 360 Platform is the <a href="/../fundamentals/architecture-basics#Platform_APIs">backwards compatibility built into the platform</a>. This means that new platform innovations may change the pattern you should use for solutions moving forward, but the everyday function of solutions you’ve built on previous Salesforce technologies will continue to work. Over time, any solution based on older technology will begin to pose risks or bottlenecks for adding new features into your apps, and lower overall solution health.</p> <p>Planning for and carrying out regular work to address technical debt is essential to maintaining healthy, straightforward designs in a Salesforce solution. Failing to plan for, audit for, and remediate technical debt is a sure way to create a system that is poorly architected.</p> <p>One way to minimize technical debt is to avoid introducing it as much as possible, by avoiding shortcuts and by preferring <a href="/../well-architected/easy/intentional#Standard_Versus_Custom_Functionality">standard functionality over custom functionality</a>. Shortcuts, like hard-coding values, may be tempting to save time, but in the long-term they create debt that must be repaid.</p> <p>The keys to addressing technical debt from an architectural perspective include:</p> <ul> <li>Identifying the actual <a href="/../resources/kpi-spreadsheet-template">cost or benefits to the business</a> of action versus inaction</li> <li>Proper <a href="/../well-architected/easy/intentional#Roadmapping">roadmapping</a></li> <li>Building <a href="/../well-architected/adaptable/composable">composable solutions</a></li> </ul> <p>The difficulty can be getting stakeholders aligned with taking action. Some stakeholders may perceive on-going maintenance as addressing “yesterday’s mistakes” or taking away from the features they want their budget to support.</p> <p>Showing the real business impacts of action and inaction, along with clearly defined deliverables and timelines can help your stakeholders understand the value and relative priority of addressing technical debt. Consistently doing the work to connect technical debt to business impacts won’t just help your stakeholders to better understand the work to be done. It will also help you ensure you’re identifying and addressing technical debt in ways that truly benefit users.</p> <p>The list of <a href="/../well-architected/easy/intentional#Maintainability_Patterns_and_Anti_Patterns">patterns and anti-patterns</a> below shows what proper (and poor) technical debt management looks like for a Salesforce org.</p> <p>To learn more about Salesforce tools that can help you with technical debt, see <a href="/../well-architected/easy/intentional#Tools_Relevant_To_Intentional">Tools Relevant to Intentional</a>.</p> <h3 id="maintainability-patterns-and-anti-patterns">Maintainability Patterns and Anti-Patterns</h3> <p>The following table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.</p> <p>✨ Discover more patterns for maintainability in the <a href="/../well-architected/explorer?Easy=Maintainability">Pattern & Anti-Pattern Explorer</a>.</p> <table> <colgroup> <col span="1" style="width: 10%;"> <col span="1" style="width: 45%;"> <col span="1" style="width: 45%;"> </colgroup> <tbody> <tr> <th scope="colgroup"></th> <th scope="colgroup">Patterns</th> <th scope="colgroup">Anti-Patterns</th> </tr> <tr> <td rowspan="5"><b>Standard vs. Custom</b></td> <td><b>In your design standards:</b> <br> - There is a clear guiding principle to keep solutions from unnecessary customization <br> - The guiding principle for solutions uses the following priority: 1. Use built-in platform services, 2. Consider AppExchange apps before building a custom solution, 3. Use low-code customizations before writing code</td> <td><b>In your design standards:</b> <br> - Design standards either don't exist or don't have a clear rationale for avoiding unneeded customizations and code</td> </tr> <tr> <td><b>In your documentation:</b> <br> - Decision records show calculation for near- and long-term costs when choosing to build or buy solutions</td> <td><b>In your documentation:</b> <br> - Decision records do not consider both near- and long-term costs when choosing to build or buy solutions</td> </tr> <tr> <td><b>In data models:</b> <br> - No objects have names or functionality that duplicates standard objects <br> - Standard objects are not used for purposes that are far outside their intended scope</td> <td><b>In data models:</b> <br> - Objects duplicate the names and/or functionality of standard objects <br> - Standard objects are used for purposes far outside their intended scope</td> </tr> <tr> <td><b>In LWC, Aura, or Visualforce:</b> <br> - No code exists to override standard page view mechanisms</td> <td><b>In LWC, Aura, or Visualforce:</b> <br> - Code exists to override standard page view mechanisms, often in the form of a single page app</td> </tr> <tr> <td><b>In LWC, Aura, or Apex:</b> <br> - No code attempts to override or circumvent the platform order of execution</td> <td><b>In LWC, Aura, or Apex:</b> <br> - Code attempts to override or circumvent the platform order of execution</td> </tr> <tr> <td rowspan="3"><b>Technical Debt</b></td> <td><b>In your roadmap:</b> <br> - Work to address tech debt is planned <br> - Deliverables and begin/end dates are clear</td> <td><b>In your roadmap:</b> <br> - No work to address tech debt is planned <br> - Deliverables are vague; begin/end dates are unclear</td> </tr> <tr> <td><b>In your decision records:</b> <br> - KPIs for pre-/post- tech debt remediation are clearly documented <br> - Trade-off discussions for action and inaction focus on business costs or benefits</td> <td><b>In your decision records:</b> <br> - Tech debt remediation has no measurable KPIs <br> - Tech debt is considered in technical or IT-focused terms, with no relevance to the business</td> </tr> <tr> <td><b>In your org:</b> <br> - No unsupported or legacy technology is active, including: <br> -- All users work in Lightning Experience <br> -- no or very few uses of <code>@future</code> in Apex (Queueable is used) <br> -- All third-party Apex belongs to AppExchange packages <br> -- no active Workflow Rules (Flow is used) <br> -- no active Process Builder processes (Flow is used) <br> -- PushTopic Events (Change Data Capture is used) <br> -- Generic Events (Platform Events are used) <br> -- API versions prior to 30.0 <br> -- Salesforce org connections use Cross-Org Adapter for Salesforce Connect</td> <td><b>In your org:</b> <br> - Unsupported or legacy technology is active, including: <br> -- Users working in Salesforce Classic <br> -- <code>@future</code> usage in Apex <br> -- Third-party Apex from non-AppExchange sources <br> -- Workflow Rules <br> -- Process Builder processes <br> -- PushTopic Events <br> -- Generic Events <br> -- API versions prior to 30.0 <br> -- Salesforce to Salesforce connections</td> </tr> </tbody> </table> <h2 id="readability">Readability</h2> <p>At its core, the concept of <em>readability</em> is about creating consistency that makes it easy for people to understand how things work. Building readable systems aligns delivery and maintenance teams, and helps people who are unfamiliar with the system quickly understand how pieces fit together. It means your team can be less dependent on individual people with institutional or historical knowledge to effectively onboard vendors or new team members. It means skilled individuals on a team can focus on the quality and trade-offs of the choices being made, because the system’s configuration and code are easy for humans to read and understand. Readability can speed up governance and quality assurance processes, and help teams better identify when they might be creating redundant customizations. It can also boost the chances of having a system that behaves in ways that are reusable and testable.</p> <p>You can increase readability via effective design standards and documentation.</p> <h3 id="design-standards">Design Standards</h3> <p><a href="/../resources/design-standards-template">Design standards</a> provide guidance to keep all customizations consistent, even at the earliest stages of development. Design standards act like guardrails, keeping all delivery teams and maintenance teams working on your system aligned on how to approach and implement customizations. Defining design standards helps boost the productivity of your delivery and maintenance teams, makes code and architectural reviews easier to conduct, and provides a basis for better <a href="/../well-architected/easy/intentional#Documentation">documentation</a>.</p> <p>Without design standards, teams are more likely to work in silos. Without the coherence that design standards provide, businesses will find themselves struggling with:</p> <ul> <li>Vendors and development teams using ad hoc patterns and approaches across solutions, potentially introducing anti-patterns and reducing reusability (see <a href="/../well-architected/adaptable/composable#Separation_Of_Concerns">Separation of Concerns</a>).</li> <li>Increased time to resolve production issues, and support teams required to onboard new team members and help them understand a disparate set of patterns and approaches.</li> <li>Poor cross-team collaboration, redundancies in work across teams, time lost resolving conflicts, and bugs discovered during integration testing.</li> <li>Increased frustration and higher turnover rates.</li> </ul> <p>A key benefit of design standards stems from the conversations and decisions stakeholders must make to create them. Specifically, the process gives your business and technology leads the opportunity to align around what optimal design looks like for your business.</p> <p>Include the following in your <a href="/../resources/design-standards-template">design standards</a></p> <ul> <li><strong>Naming conventions for Salesforce metadata</strong>. Define a set of conventions for how every customization in a system is to be named. Good naming conventions don’t just enforce consistency across the names of objects, fields, code, flows, and other elements of your system. Good naming conventions also help development teams to use names that convey information about the purpose and functionality of what they’re building. As a result, other stakeholders can better understand a particular customization, just by seeing its name.</li> <li><strong>Approved design patterns and their use cases</strong>. Establish a library of <a href="/../diagrams/#design-patterns">patterns</a>, along with key information about when (and when not) to use each pattern. The library might include required Apex trigger patterns, or flow orchestration patterns based on the <a href="/../well-architected/adaptable/composable">composability</a> you want in your system.</li> <li><strong>Development environment and tool guidance</strong>. Maintain a clear list of the tools development teams are to use for their work. This could include approved tool chains and languages for anyone writing code, or declarative features that are (or are not) approved for low-code development. Your standards might include a list of source control systems for customization and documentation, and required check-in/check-out steps. They might also include a list of environments to be used for different kinds of development work.</li> </ul> <p>Along with defining these standards, you’ll need to decide how and where to maintain and store them. If teams across your company can’t find your design standards (or aren’t even aware they exist), they won’t be effective. Ideally, your design standards live within the same system as your documentation (see the next section for more).</p> <p>The list of <a href="/../well-architected/easy/intentional#Readability_Patterns_and_Anti_Patterns">patterns and anti-patterns</a> below shows what proper (and poor) design standards look like for a Salesforce org. You can use these to validate or improve your design standards.</p> <p>To learn more about Salesforce tools that can help you define design standards, see <a href="/../well-architected/easy/intentional#Tools_Relevant_To_Intentional">Tools Relevant to Intentional</a>.</p> <h3 id="documentation">Documentation</h3> <p>Documentation explains the what, how, and why of your system. Without meaningful and consistent documentation, teams waste a lot of time trying to understand the system as it is (and potentially misunderstanding features and customizations).</p> <p>Good documentation takes time to create. While most teams agree that documentation is important for large projects, it can be a tempting step to skip when making quick changes like configuration updates or minor tweaks to an automation. Not documenting the changes you make to your system is always an anti-pattern. Skipping documentation may save a small amount of time upfront, but the amount of time required to troubleshoot an org that isn’t properly documented will more than cancel out those time savings. Always include enough time to create documentation in all of your estimates, regardless of the level of effort required for the updates you’re planning to make.</p> <p>The lack of clear documentation can lead to a variety of problems, including:</p> <ul> <li>Development cycles spent on reworking existing implementations</li> <li>Repetitive discussions revisiting or puzzling over previous decisions</li> <li>Longer onboarding for new team members or vendors</li> <li>Over-dependence on individuals with institutional or historical knowledge</li> <li>Redundant architectures to support the same or similar capabilities across the business</li> <li>Difficulty in communicating the purpose and value of your solution to key stakeholders</li> </ul> <p>For Salesforce solutions, maintain documentation for:</p> <ul> <li><strong>Solution overviews</strong>. <a href="/../diagrams/framework/overview">Diagrams</a> enable you and your stakeholders to visualize solutions at various levels of detail. The Salesforce diagram framework helps you create diagrams that show the business capabilities of solutions, as well as technical implementation details.</li> <li><strong>Decision records</strong>. Keep a record of the options considered, trade-offs, final decision, and reasoning in a central location that all team members can access for future reference.</li> <li><strong>Code</strong>. The format of code itself is a key piece of documentation, and this can (and should) align with your <a href="/../well-architected/easy/intentional#Design_Standards">design standards</a>. You will also want to have a log of key information, and update it with every modification of a piece of code. For all classes, triggers, and components, document the following: <ul> <li>Who authored the code</li> <li>When the code was written</li> <li>What the code is supposed to do</li> <li>Key dependencies</li> <li>All changes</li> </ul> </li> <li><strong>Declarative customization</strong>. For every kind of customization that can be made to the metadata in your org, Salesforce provides <a href="/../fundamentals/platform-multitenant-architecture#Browser_Based__No_Code__and_Low_Code_Application_Development">built-in attributes</a> for teams to provide helpful information about the purpose and intent of the metadata. As part of your design standards, include how teams are to use these built-in features and how they are to name declarative customizations. Also maintain a log of key information that is identical to what you use for code.</li> </ul> <p>Develop a set of documentation standards to ensure that all current and future team members will be able to interpret documents the same way. (<a href="/../resources/design-standards-template">design standards</a> can help with this.) It’s also important to consider how users will be able to search documentation to find relevant sections or terms. As your system ages and grows in complexity, your documentation will also grow. The usefulness of the information in your documentation will be directly related to how often, how quickly, and how easily users can search for and find relevant items.</p> <p>The list of <a href="/../well-architected/easy/intentional#Readability_Patterns_and_Anti_Patterns">patterns and anti-patterns</a> below shows what proper (and poor) documentation looks like for a Salesforce org. You can use these to validate or improve your documentation strategy.</p> <p>To learn more about Salesforce tools for documentation, see <a href="/../well-architected/easy/intentional#Tools_Relevant_To_Intentional">Tools Relevant to Intentional</a>.</p> <h3 id="readability-patterns-and-anti-patterns">Readability Patterns and Anti-Patterns</h3> <p>The following table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.</p> <p>✨ Discover more patterns for readability in the <a href="/../well-architected/explorer?Easy=Readability">Pattern & Anti-Pattern Explorer</a>.</p> <table> <colgroup> <col span="1" style="width: 10%;"> <col span="1" style="width: 45%;"> <col span="1" style="width: 45%;"> </colgroup> <tbody> <tr> <th scope="colgroup"></th> <th scope="colgroup">Patterns</th> <th scope="colgroup">Anti-Patterns</th> </tr> <tr> <td rowspan="2"><b>Design Standards</b></td> <td><b>In your org:</b> <br> - Code and declarative customizations have consistent, human-readable names <br> - Data models have consistent, uniform names for objects and fields <br> - Audits show fields are consistently filled out and referenced in reports, etc.</td> <td><b>In your org:</b> <br> - Code and declarative customizations do not have consistent names <br> - Data models have inconsistent names and many objects and fields seem to be redundant <br> - Audits show many unused fields or various levels of usage, and there is no consistent link to reporting, etc.</td> </tr> <tr> <td><b>Within your business:</b> <br> - Teams know what tools to use (and not use) to get work done <br> - Approved design patterns are easy to find and identify by use case <br> - Approved AI models are clearly identified and include an intended purpose</td> <td><b>Within your business:</b> <br> - Teams use many different tools to get similar work done <br> - There are no approved design patterns <br> - It takes a lot of time for vendors or new employees to onboard <br> - Approved AI models are not clearly identified, and their intended purpose is unclear</td> </tr> <tr> <td rowspan="2"><b>Documentation</b></td> <td><b>In your org:</b> <br> - Code and declarative customizations have clear descriptions</td> <td><b>In your org:</b> <br> - Code and declarative customizations do not have descriptions, have descriptions that are difficult to understand, or have descriptions that don't seem to match what the customization is actually doing</td> </tr> <tr> <td><b>Within your business:</b> <br> - Diagrams for business capabilities and technical implementation details exist for all solutions <br> - Key who/when/what information logs exist for code and declarative customizations <br> - People can search for and find relevant documentation</td> <td><b>Within your business:</b> <br> - The what/how/why of solutions is hard to find and may be unavailable to most teams <br> - People struggle to understand solutions and the system they are working with <br> - It takes a lot of time for vendors or new employees to onboard</td> </tr> </tbody> </table> <h2 id="tools-relevant-to-intentional">Tools Relevant to Intentional</h2> <table class="tools-table"><tbody><tr><th>Tool</th><th>Description</th><th>Strategy</th><th>Maintainability</th><th>Readability</th></tr> <tr><td><a href="https://github.com/SalesforceFoundation/ApexDoc">ApexDoc</a></td><td>Document Apex with static HTML pages</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr> <tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_picklist_delete_inactive_values.htm&language=en_US&type=5&_ga=2.216886358.1142927923.1683068265-1808100124.1682614163">Bulk Delete Inactive Picklist Values</a></td><td>Delete inactive unused values from picklists</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="https://architect.salesforce.com/diagrams/#design-patterns">Design Patterns</a></td><td>Explore design patterns and templates</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr> <tr><td><a href="https://www.lightningdesignsystem.com/tools/validator/">Lightning Design System Validator</a></td><td>Validate markup and see how to improve your code</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr> <tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_mgmt_migrate_to_flow_tool.htm&type=5&release=242&_ga=2.180751207.1142927923.1683068265-1808100124.1682614163">Migrate to Flow</a></td><td>Convert Workflow Rules and Process Builder processes into flows</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3u00000MRsKnEAL">Project Management Tool by Salesforce Labs</a></td><td>Manage projects within your Salesforce Org</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">Salesforce Extensions for Visual Studio Code (Expanded)</a></td><td>Analyze Salesforce code efficiently with Visual Studio Code Extensions</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr> <tr><td><a href="https://sfdc.co/OrgCheck">Org Check</a></td><td>Quickly analyze your org and its technical debt</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="https://forcedotcom.github.io/sfdx-scanner/">Salesforce Code Analyzer</a></td><td>Scan code via IDE, CLI or CI/CD to ensure it adheres to best practices</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr> <tr><td><a href="https://architect.salesforce.com/roadmaps/roadmap-explorer">Salesforce Roadmap Explorer</a></td><td>Explore Salesforce product innovations</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr> <tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5">Setup Audit Trail</a></td><td>Track setup changes and audit history</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr> </tbody></table> <h2 id="resources-relevant-to-intentional">Resources Relevant to Intentional</h2> <table class="tools-table"><tbody><tr><th>Resource</th><th>Description</th><th>Strategy</th><th>Maintainability</th><th>Readability</th></tr> <tr><td><a href="https://www.salesforce.org/blog/5-documentation-strategies-to-improve-your-salesforce-org/">5 Documentation Strategies to Improve Your Salesforce Org</a></td><td>Improve Salesforce implementation documentation</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr> <tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/choose-naming-conventions-sc">Choose Naming Conventions (Trailhead)</a></td><td>Learn how to apply naming conventions</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr> <tr><td><a href="https://medium.com/salesforce-architects/defining-identifying-and-measuring-technical-debt-5f783e2b381d">Defining, Identifying, and Measuring Technical Debt</a></td><td>Define, identify and measure technical debt</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="/../resources/design-standards-template">Design Standards Template</a></td><td>Create design standards for your organization</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr> <tr><td><a href="https://architect.salesforce.com/diagrams/#getting-started">Get Started with Salesforce Diagrams</a></td><td>Learn how to create the right diagram for your use case</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr> <tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/get-started-with-coding-conventions-sc">Getting Started with Coding Conventions (Trailhead)</a></td><td>Define and follow coding conventions</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr> <tr><td><a href="https://trailhead.salesforce.com/trailblazer-community/download/file/0693A000006PskRQAS">How to Tackle Technical Debt (Trailhead)</a></td><td>Manage technical debt in your Salesforce org</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/improve-your-apex-code-sc">Improve Your Apex Code (Trailhead)</a></td><td>Apply basic principles of test-driven development</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr> <tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">Organizational Alignment (Trailhead)</a></td><td>Learn the V2MOM process for alignment</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr> <tr><td><a href="https://medium.com/salesforce-architects/prioritizing-and-planning-a-way-out-of-technical-debt-6f18fbb2b007">Prioritizing and Planning a Way Out of Technical Debt</a></td><td>Form a plan to reduce and remove technical debt</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="https://salesforce.quip.com/MW5cAPVwat8k#JCIACA8Q963">Salesforce Naming Conventions Template</a></td><td>Get started with naming conventions</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr> <tr><td><a href="https://admin.salesforce.com/blog/2021/tech-debt-what-it-is-and-why-you-should-care">Technical Debt: What Is It and Why Should You Care? </a></td><td>Understand the impact of technical debt in your org</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr> <tr><td><a href="https://medium.com/salesforce-architects/using-the-business-model-canvas-in-enterprise-architecture-5c136803a99d">Using the Business Model Canvas in Enterprise Architecture</a></td><td>Create, deliver, and see value in a business model</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr> </tbody></table> <h2 id="tell-us-what-you-think">Tell us what you think</h2> <p>Help us keep Salesforce Well-Architected relevant to you; take our <a href="https://sfdc.co/bxNtvh">survey</a> to provide feedback on this content and tell us what you’d like to see next.</p> </tm-content> </div> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "headline": "Intentional", "image": ["https://architect.salesforce.com/assets/images/cards/intentional.png"], "author": "Salesforce Architects", "publisher": { "@type": "Organization", "name": "Salesforce", "logo": { "@type": "ImageObject", "url": "https://architect.salesforce.com'/assets/images/favicon-192x192.png" } }, "url": "https://architect.salesforce.com", "mainEntityOfPage": "https://architect.salesforce.com/well-architected/easy/intentional", "datePublished": "July 2024", "dateModified": "July 2024", "description": "Read about our update schedules here. Introduction Intentional solutions deliver business value immediately and over time. Intentional..." } </script> <footer> <tds-footer config="{"columns":[{"heading":"Well-Architected","links":[{"href":"/well-architected/overview","label":"Overview"},{"href":"/well-architected/trusted/overview","label":"Trusted"},{"href":"/well-architected/easy/overview","label":"Easy"},{"href":"/well-architected/adaptable/overview","label":"Adaptable"},{"href":"/well-architected/explorer","label":"Pattern & Anti-Pattern Explorer"}]},{"heading":"Diagrams","links":[{"href":"/diagrams/#framework","label":"Salesforce Diagrams Overview"},{"href":"/diagrams/#reference-architecture-gallery","label":"Reference Architecture Gallery"},{"href":"/diagrams/#data-model-gallery","label":"Data Model Gallery"}]},{"heading":"Decision Guides","links":[{"href":"/decision-guides/event-driven","label":"Event-Driven Architectures"},{"href":"/decision-guides/data-integration","label":"Data Integration"},{"href":"/decision-guides/trigger-automation","label":"Record-Triggered Automation"},{"href":"/decision-guides/build-forms","label":"Building Forms"},{"href":"/decision-guides","label":"See All Guides"}]},{"heading":"Fundamentals","links":[{"href":"/fundamentals/platform-transformation","label":"Platform Transformation"},{"href":"/fundamentals/architecture-basics","label":"Architecture Basics"},{"href":"/fundamentals/platform-multitenant-architecture","label":"Platform Multitenant Architecture"},{"href":"/fundamentals/platform-sharing-architecture","label":"Plaform Sharing Architecture"}]},{"heading":"Resources","links":[{"href":"/resources/project-resource-gallery/ai","label":"Project Resource Gallery"},{"href":"/roadmaps/roadmap-explorer","label":"Roadmap Explorer"},{"href":"/releases","label":"Release Overviews"}]},{"heading":"Connect","links":[{"href":"/connect/blog","label":"Our Blog"},{"href":"https://www.youtube.com/c/SalesforceArchitects","label":"Our Youtube Channel"},{"href":"https://trailblazer.salesforce.com/about","label":"Trailblazer Community"}]}],"global":{"logo":{"assistiveText":"Salesforce Logo","url":"/assets/images/salesforce-corp-logo.jpg"},"copyrightTitle":"© Copyright 2024 Salesforce, Inc. ","copyrightEnd":" Various trademarks held by their respective owners. Salesforce, Inc. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States","links":[{"href":"https://www.salesforce.com/company/legal/","label":"Legal","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/legal/sfdc-website-terms-of-service/","label":"Terms of Service","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/legal/privacy/","label":"Privacy Information","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/disclosure/","label":"Responsible Disclosure","target":"_blank","rel":"noopener"},{"href":"https://trust.salesforce.com/","label":"Trust","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/company/contact-us/?d=cta-glob-footer-11","label":"Contact","target":"_blank","rel":"noopener"},{"href":"https://www.salesforce.com/form/other/privacy-request/","label":"Your Privacy Choices","target":"_blank","rel":"noopener","icon":"/assets/images/privacyicon.png"}]}}"></tds-footer> </footer> <script type="application/javascript">/* This script is generated */ /* Client Bootstrap configuration */ globalThis.LWR = globalThis.LWR || {}; Object.assign(globalThis.LWR, {"appId":"genericRouteHandler","bootstrapModule":"@lwrjs/app-service/genericRouteHandler/module/esm/v/0_11_15","autoBoot":true,"imports":{"/1/bundle/esm/l/en-US/bi/0/module/mi/%40lwrjs%2Fapp-service%2FgenericRouteHandler%2Fmodule%2Fesm%2Fv%2F0_11_15/s/b6ad7971baa5047e7bbcc1e3720daf77d2e9a4e8/bundle_@lwrjs_app-service_genericRouteHandler_module_esm.js":["@lwrjs/app-service/genericRouteHandler/module/esm/v/0_11_15"],"/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Fheader%2Fv%2F1_0_1/s/f1ae5fd3b59a385b871f876495d5741e0957add6/bundle_tds_header.js":["tds/header/v/1_0_1"],"/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Fsearch%2Fv%2F1_0_1/s/ba146dfefa0db013dde40c32eb477d1546205919/bundle_tds_search.js":["tds/search/v/1_0_1"],"/1/bundle/esm/l/en-US/bi/0/module/mi/tm%2FpageHeaderA%2Fv%2F1_0_1/s/c8f9c55107f494dec9b72e13a6bb453e5f9f65bd/bundle_tm_pageHeaderA.js":["tm/pageHeaderA/v/1_0_1"],"/1/bundle/esm/l/en-US/bi/0/module/mi/tm%2Fcontent%2Fv%2F1_0_1/s/dee4bef2d0f5ca8a26d7c6e1b844af5611d11762/bundle_tm_content.js":["tm/content/v/1_0_1"],"/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Ffooter%2Fv%2F1_0_1/s/1f66aa6c773f6411635ee086a6f51d1560c26190/bundle_tds_footer.js":["tds/footer/v/1_0_1"],"/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Finstrumentation%2Fv%2F1_0_1/s/9c0fc260e15d54da8ccbbd08bcaf7480b9943fff/bundle_tds_instrumentation.js":["tds/instrumentation/v/1_0_1"]},"index":{"@lwrjs/app-service/genericRouteHandler/module/esm/v/0_11_15":"/1/module/esm/0/l/en-US/mi/%40lwrjs%2Fapp-service%2FgenericRouteHandler%2Fmodule%2Fesm%2Fv%2F0_11_15/latest/@lwrjs_app-service_genericRouteHandler_module_esm.js","tds/header/v/1_0_1":"/1/module/esm/0/l/en-US/mi/tds%2Fheader%2Fv%2F1_0_1/latest/tds_header.js","tds/search/v/1_0_1":"/1/module/esm/0/l/en-US/mi/tds%2Fsearch%2Fv%2F1_0_1/latest/tds_search.js","tm/pageHeaderA/v/1_0_1":"/1/module/esm/0/l/en-US/mi/tm%2FpageHeaderA%2Fv%2F1_0_1/latest/tm_pageHeaderA.js","tm/content/v/1_0_1":"/1/module/esm/0/l/en-US/mi/tm%2Fcontent%2Fv%2F1_0_1/latest/tm_content.js","tds/footer/v/1_0_1":"/1/module/esm/0/l/en-US/mi/tds%2Ffooter%2Fv%2F1_0_1/latest/tds_footer.js","tds/instrumentation/v/1_0_1":"/1/module/esm/0/l/en-US/mi/tds%2Finstrumentation%2Fv%2F1_0_1/latest/tds_instrumentation.js"},"rootComponents":["tds/header/v/1_0_1","tds/search/v/1_0_1","tm/pageHeaderA/v/1_0_1","tm/content/v/1_0_1","tds/footer/v/1_0_1","tds/instrumentation/v/1_0_1"],"serverData":{},"endpoints":{"uris":{"mapping":"/1/mapping/esm/0/l/en-US/bi/0/mp/","module":"/1/bundle/esm/l/en-US/bi/0/module/mi/"}}}); globalThis.process = { env: {"NODE_ENV":"prod","SSR":false,"basePath":"","locale":"en-US","assetBasePath":"","uiBasePath":""} }; globalThis.lwcRuntimeFlags = { ENABLE_MIXED_SHADOW_MODE: false };</script> <script type="module" src="/1/bundle/esm/l/en-US/bi/0/module/mi/%40lwrjs%2Fapp-service%2FgenericRouteHandler%2Fmodule%2Fesm%2Fv%2F0_11_15/s/b6ad7971baa5047e7bbcc1e3720daf77d2e9a4e8/bundle_@lwrjs_app-service_genericRouteHandler_module_esm.js"></script> <link rel="modulepreload" href="/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Fheader%2Fv%2F1_0_1/s/f1ae5fd3b59a385b871f876495d5741e0957add6/bundle_tds_header.js" /> <link rel="modulepreload" href="/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Fsearch%2Fv%2F1_0_1/s/ba146dfefa0db013dde40c32eb477d1546205919/bundle_tds_search.js" /> <link rel="modulepreload" href="/1/bundle/esm/l/en-US/bi/0/module/mi/tm%2FpageHeaderA%2Fv%2F1_0_1/s/c8f9c55107f494dec9b72e13a6bb453e5f9f65bd/bundle_tm_pageHeaderA.js" /> <link rel="modulepreload" href="/1/bundle/esm/l/en-US/bi/0/module/mi/tm%2Fcontent%2Fv%2F1_0_1/s/dee4bef2d0f5ca8a26d7c6e1b844af5611d11762/bundle_tm_content.js" /> <link rel="modulepreload" href="/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Ffooter%2Fv%2F1_0_1/s/1f66aa6c773f6411635ee086a6f51d1560c26190/bundle_tds_footer.js" /> <link rel="modulepreload" href="/1/bundle/esm/l/en-US/bi/0/module/mi/tds%2Finstrumentation%2Fv%2F1_0_1/s/9c0fc260e15d54da8ccbbd08bcaf7480b9943fff/bundle_tds_instrumentation.js" /> <tds-instrumentation use-google-tag-manager="true"></tds-instrumentation> </body> </html>