License Optimization - Patterns
Learn more about Well-Architected Resource and Cost Optimization → 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 |