# License Optimization - Patterns | Patterns Source: https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization-license-patterns.html > Proven patterns for license right-sizing, add-on investment, governance, contract optimization, and multi-org license management aligned to the Well-Architected Resource and Cost Optimization pillar. # License Optimization - Patterns Learn more about Well-Architected [Resource and Cost Optimization](https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization.html) → [Licensing and Consumption](https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization.html#licensing-and-consumption) **Patterns** Where to look What good looks like Platform | Org ✅ License types are matched to actual user requirements and usage patterns (not job titles) Platform | Org ✅ Users accessing only custom objects receive Platform licenses instead of full Salesforce licenses Platform | Org ✅ External users (customers, partners, community members) use Experience Cloud licenses rather than internal licenses Platform | Org ✅ Users requiring only authentication without data access receive Identity licenses Platform | Org ✅ Quarterly license audits identify users accessing only custom objects as Platform license candidates Platform | Org ✅ Automated quarterly reports identify users with zero logins in 90 days, users accessing only custom objects, and external users on internal licenses for systematic right-sizing Platform | Org ✅ License assignments are reviewed and adjusted based on role changes rather than remaining unchanged for years **Anti-Patterns** Where to look What bad looks like Platform | Org ⚠️ Full Salesforce licenses are assigned to all employees based on job title rather than actual system usage patterns Platform | Org ⚠️ Users accessing only custom objects receive full Sales Cloud or Service Cloud licenses instead of Platform licenses Platform | Org ⚠️ External users consume internal license capacity instead of Experience Cloud licenses Platform | Org ⚠️ License assignments set during initial deployment remain unchanged for three years despite role changes Platform | Org ⚠️ License audits are never conducted; 40% of licenses are unused or underutilized Platform | Org ⚠️ Users logging in fewer than monthly are not identified as candidates for license reclamation **Patterns** Where to look What good looks like Platform | Security ✅ Shield components (Platform Encryption, Event Monitoring, Field Audit Trail) are evaluated individually based on whether they address specific compliance needs Data 360 | Architecture ✅ Data 360 investment is justified by requirements for cross-system identity resolution, real-time customer data access, or segment activation AI | Business ✅ AI investment requires demonstrated ROI within defined measurement periods rather than assuming unspecified value Platform | Industry Clouds ✅ Industry Clouds (Financial Services, Health, Manufacturing, Net Zero) are evaluated against custom development costs and time-to-market requirements Platform | Industry Clouds ✅ Industry Cloud evaluation recognizes 40-60% faster implementation for standard workflows but accounts for customization reducing time savings **Anti-Patterns** Where to look What bad looks like Platform | Security ⚠️ All Shield components are purchased without evaluating whether specific components address actual compliance or security needs Data 360 | Architecture ⚠️ Data 360 is purchased without evaluating whether simpler integration approaches meet requirements AI | Business ⚠️ AI investment lacks measurable business value metrics or ROI demonstration AI | Business ⚠️ AI investment assumes value will be delivered without defining specific measurement periods or success criteria Platform | Industry Clouds ⚠️ Industry Clouds are purchased without comparing to custom development costs or validating time-to-market acceleration **Patterns** Where to look What good looks like Platform | Provisioning ✅ New user provisioning workflow automatically assigns Platform licenses for users accessing only custom apps Platform | Provisioning ✅ New user provisioning workflow queues external users for Experience Cloud license assignment based on email domain Platform | Provisioning ✅ Assignment policies define clear criteria for license types based on user role and platform usage requirements Platform | Provisioning ✅ Approval workflows require business justification for premium license types Platform | Provisioning ✅ Appropriate license assignment is enforced at provisioning time rather than correcting misassignments retroactively Platform | Org ✅ Reclamation processes automatically identify inactive users (60-90 days) and reclaim unused licenses for reassignment Platform | Org ✅ Login-based reports identify users inactive for 60-90 days based on organizational policies Platform | Org ✅ Quarterly reclamation prevents license waste from accumulating as employees change roles or leave the organization Platform | KPIs ✅ Utilization monitoring dashboards track login frequency, feature usage patterns, and license type appropriateness Platform | Business ✅ Utilization data is shared with business leaders enabling data-driven license investment decisions during renewal planning **Reports & Dashboards** → License Utilization Dashboard **Setup** → Users → Active Users ✅ **Pattern**: License utilization dashboards show active versus inactive licenses, login frequency distribution, feature usage by license type, and license type distribution ✅ Utilization dashboards reveal inactive users, over-licensed users, and license type mismatches requiring review **Anti-Patterns** Where to look What bad looks like Platform | Provisioning ⚠️ License assignment policies do not exist; each request is handled ad hoc Platform | Provisioning ⚠️ Approval workflows do not require business justification for premium license types Platform | Org ⚠️ Inactive user identification is manual and infrequent rather than automated Platform | Org ⚠️ License reclamation happens only during annual renewal rather than quarterly Platform | Org ⚠️ License waste accumulates for years as employees change roles or leave without license reclamation Platform | KPIs ⚠️ Utilization monitoring dashboards do not exist; usage patterns are unknown Platform | Business ⚠️ Business leaders lack visibility into license utilization data during renewal planning **Patterns** Where to look What good looks like Platform | Contracts ✅ User count commitments are supported by business plans rather than optimistic forecasts Platform | Contracts ✅ Ramp schedules match investment to actual user onboarding timeline rather than paying for unused capacity in advance **Anti-Patterns** Where to look What bad looks like Platform | Contracts ⚠️ Over-committing to user counts creates immediate waste through unused licenses consuming budget without delivering value Platform | Contracts ⚠️ Multi-year agreements are signed without evaluating flexibility needs if growth projections prove incorrect Platform | Contracts ⚠️ True-up timing does not match business planning cycles; adjustments lag behind actual headcount changes Platform | Contracts ⚠️ Organization carries 200 unused licenses for 18 months because hiring plan delays after committing to achieve volume discount **Patterns** Where to look What good looks like Platform | Architecture ✅ Integration architecture planning projects API consumption and evaluates whether Enterprise or Unlimited Edition provides better TCO Platform | Architecture ✅ Edition cost comparison models per-user premium against included capabilities (API limits, storage, sandbox allocations, Premier Support) Platform | Architecture ✅ Edition decision models projected usage against both pricing models with documented assumptions enabling future reassessment **Anti-Patterns** Where to look What bad looks like Platform | Architecture ⚠️ Edition selection defaults to highest or lowest tier based on budget constraints without analyzing architectural requirements Platform | Architecture ⚠️ Enterprise Edition is selected to minimize per-user cost without projecting integration requirements and API overage costs Platform | Architecture ⚠️ Integration requirements exceed limits after deployment, resulting in 2x cost through API overages plus architectural rework Platform | Architecture ⚠️ Edition decision is made without modeling actual usage against both pricing models or documenting assumptions Platform | Org ⚠️ Edition selection is based solely on per-user annual subscription cost without modeling architectural constraints **Patterns** Where to look What good looks like Platform | Architecture ✅ Single-org optimization approaches (sharing rules, permission sets, record types) are evaluated before adopting multi-org architecture Platform | Architecture ✅ Multi-org TCO model shows 2-3x operational cost multiplication including administration, release management, monitoring, incident response, and compliance Platform | Architecture ✅ Multi-org architecture is adopted only when regulatory requirements (GDPR data residency, financial separation) offset increased costs Platform | Architecture ✅ Multi-org justification documents genuine isolation requirements that single-org with permission boundaries cannot meet Platform | Contracts ✅ Multi-org license costs model separate license pools per org losing volume pricing and requiring duplicate administrative licenses Platform | Architecture ✅ Multi-org operational costs model parallel maintenance across multiple implementations multiplying development and operational effort **Anti-Patterns** Where to look What bad looks like Platform | Architecture ⚠️ Multi-org architecture is adopted because business units “want independence” without modeling 2-3x cost multiplication Platform | Architecture ⚠️ Multi-org adoption happens without evaluating whether single-org with sharing rules would meet actual requirements at fraction of cost Platform | Architecture ⚠️ Multi-org TCO model does not include operational cost multiplication (2-3x for admin, release management, monitoring, compliance) Platform | Architecture ⚠️ Multi-org architecture lacks documented business justification demonstrating value exceeds permanent and compounding cost multiplication Platform | Contracts ⚠️ Multi-org license cost analysis does not account for separate license pools losing volume pricing benefits Platform | Architecture ⚠️ Multi-org operational burden is not modeled; parallel maintenance across orgs is discovered after deployment **Patterns** Where to look What good looks like Platform | Integration ✅ Multi-org TCO includes MuleSoft licensing ($20K-$200K+ annually), integration development, ongoing maintenance, and API capacity planning Platform | Integration ✅ Cross-org integration costs are modeled explicitly showing MuleSoft investment, development effort, and sustained operational costs Platform | Architecture ✅ API consumption multiplication is modeled: cross-org transactions consuming 5-10 API calls across multiple orgs simultaneously Platform | Integration ✅ Data consistency overhead for maintaining synchronized reference data across orgs includes development effort, monitoring, and conflict resolution **Anti-Patterns** Where to look What bad looks like Platform | Integration ⚠️ Multi-org architecture is approved based on license cost comparison without modeling $240K annual integration costs Platform | Integration ⚠️ Cross-org integration costs are not explicitly modeled; single-org would eliminate these costs entirely Platform | Architecture ⚠️ API consumption multiplication from cross-org calls is not accounted for in capacity planning Platform | Integration ⚠️ Data consistency overhead for synchronized reference data is not included in multi-org TCO model **Patterns** Where to look What good looks like **Setup** → Sandboxes → Environment Strategy **DevOps** → Sandbox Allocation Plan ✅ **Pattern**: Team uses Developer Pro sandboxes for feature development with mock data, Partial Copy with targeted accounts for integration testing ✅ Reserves Full Copy exclusively for pre-production UAT and performance validation where complete data volume is architecturally necessary **Setup** → Sandboxes → Balanced Strategy **Finance** → Environment Budget ✅ **Pattern**: 15-person development team implements balanced strategy with 15 Developer Pro sandboxes ($750 monthly), 3 Partial Copy for parallel work streams ($900 monthly), 1 Full Copy for UAT ($3,000 monthly) ✅ Totals $4,650 monthly matching actual development patterns rather than over-provisioning for theoretical maximum parallelism **Setup** → Sandbox Templates → Data Selection **Setup** → Partial Copy Configuration ✅ **Pattern**: Partial Copy sandbox template includes last 12 months of opportunities and cases but excludes archived data ✅ Provides representative testing data within 5 GB capacity rather than requiring Full Copy, enabling lower-cost sandbox type through strategic data selection **Process** → Sandbox Lifecycle **Setup** → Temporary Environment Tracking ✅ **Pattern**: Temporary sandbox management tracks environments created for specific projects with documented deletion dates ✅ Implement expiration policies requiring renewal justification to maintain temporary environments beyond initial scope preventing permanent status drift **Setup** → Sandbox Refresh Schedule **Calendar** → Refresh Optimization ✅ **Pattern**: Refresh cadence optimization aligns sandbox refresh with actual data freshness requirements rather than arbitrary schedules ✅ Quarterly Full Copy refresh suffices when monthly refresh is unnecessary for testing patterns, freeing capacity for additional sandboxes **Anti-Patterns** Where to look What bad looks like **Over-Provisioning** → Wasted Investment ⚠️ **Anti-Pattern**: Organization purchases five Full Copy sandboxes to give every development team dedicated environments ⚠️ Multiplies costs 5-10x when Partial Copy would meet most testing requirements; Full Copy should be reserved for scenarios requiring complete production fidelity **No Strategy** → Premium Default ⚠️ **Anti-Pattern**: 15-person team purchases premium strategy with 30 Developer Pro and 5 Full Copy sandboxes ($18,000 monthly) because “more environments are always better” ⚠️ No analysis showing development velocity constrained by environment availability; balanced strategy would deliver same velocity at $4,650 monthly **Unfiltered Templates** → Forced Upgrades ⚠️ **Anti-Pattern**: Partial Copy template includes all objects without filtering, consuming 5 GB capacity with historical data irrelevant to testing ⚠️ Forces Full Copy purchase when strategic data selection would enable Partial Copy usage at 5-10x lower cost per sandbox **Sandbox Sprawl** → Permanent Temporary ⚠️ **Anti-Pattern**: Temporary sandbox proliferation as project sandboxes transition to permanent status without justification ⚠️ No expiration policies or renewal requirements allowing temporary environments to accumulate consuming budget indefinitely