Platform Licenses vs Full CRM Licenses: When to Downgrade

The Architectural Scope of Platform Licenses (Salesforce Platform vs Enterprise CRM)

In enterprise Salesforce architectures, choosing the right user licence type is one of the most critical decisions for controlling platform costs. Solutions architects and technology leaders are frequently faced with a major question: when can users be assigned a low-cost Salesforce Platform licence instead of a full, premium Enterprise CRM user licence? Failing to understand the functional capabilities and limits of these licence types can lead to significant wasted spend, technical rework, and severe licensing audit penalties.

Functional Commonalities and Platform Rights

From an infrastructural perspective, the Salesforce Platform licence is built on the exact same multi-tenant architecture, database engine, security model, and API framework as full Sales and Service Cloud CRM licences. It is not a technically inferior platform; rather, it is commercially restricted to custom business processes. Users assigned a Salesforce Platform licence receive:

• Full Customisation Support: The ability to access custom objects (up to 110 custom objects per application), custom metadata types, custom fields, and validation rules.
• Standard Automation Engine: Full access to run and interact with Flow Builder, Apex classes, custom triggers, and standard approval processes.
• Bespoke User Interfaces: The ability to utilise custom Lightning Web Components (LWC), Visualforce pages, custom tabs, and customised utility bars.
• Standard Sharing and Security: The exact same sharing rules, role hierarchies, public groups, and field-level security (FLS) enforcement as the rest of the host organisation.
• Baseline Core Objects: Full read, write, and edit access to standard Account and Contact tables.

The Core Restrictions: What is Excluded?

The core difference between the two licence types lies in standard CRM capabilities. While a full CRM licence is designed to support customer-facing sales pipelines and client service desks, a Platform licence is intended for internal corporate workflows. Commercially and technically, the Platform licence strictly excludes access to two primary functional clouds:

1. Sales Cloud CRM Objects: Platform users have zero access to the standard opportunity pipeline tables, including Opportunity, Lead, Campaign, Forecast, Quote, and OpportunityLineItem.
2. Service Cloud CRM Objects: Platform users are technically blocked from accessing standard customer service tables, including Case, Solution, Entitlement, and KnowledgeArticle.

If a business process requires an employee to manage sales pipelines or solve external customer support requests, that user technically and commercially requires a full CRM licence. However, if the process involves internal operations—such as HR onboarding, IT asset management, expense approvals, or supply chain tracking—a Salesforce Platform licence is the ideal, cost-effective target.

Object Access Boundaries: Standard CRM Objects vs Custom Schemas

To design a compliant, cost-effective platform architecture, architects must map out the exact database boundaries of their user base. This requires a deep understanding of standard object boundaries versus custom metadata schemas, ensuring that platform configurations do not breach contractual agreements.

The Account and Contact Exception

As noted previously, the standard Account and Contact objects are shared between both CRM and Platform licences. This is a crucial architectural concession by Salesforce. It allows back-office and operations staff holding Platform licences to view, create, and update core customer accounts and associated business contacts. Platform users can also interact with standard tasks, events, activities, and notes associated with these accounts, as long as they do not reference blocked CRM tables.

However, architects must be cautious. While Platform users can access Accounts, their access to associated relational lists is limited. If a standard Account page layout includes related lists for Opportunities or Cases, these lists will be completely hidden from Platform users. If your business processes require Platform users to see opportunity history or case updates, you must not use technical workarounds to expose these tables; doing so violates Salesforce's commercial licensing terms.

Standard CRM Objects vs. Custom Object Schemas

When a business process requires database features that resemble sales pipelines or customer support, but is carried out by internal operations teams, architects often consider building custom schemas. The table below compares standard CRM tables with custom object alternatives:

Mapping VIP and Custom Objects to Ensure Compliance and Cost Savings

When migrating users from high-cost CRM licences to low-cost Platform licences, architects must address the **Very Important Objects (VIPs)**—those critical business tables that sit at the intersection of sales, service, and internal operations. Simply rebuilding standard features on custom objects to bypass licensing costs is a violation of your Salesforce agreement. Rebuilding is only compliant if the new custom objects serve a distinct, non-CRM business purpose.

Compliant Custom Schema Design

To illustrate compliant schema design, let us examine an enterprise organisation that manages both external client sales and internal corporate onboarding. The sales team uses standard Opportunities to track deals. Once a deal is won, the delivery team (holding Platform licences) must manage the onboarding project. Creating opportunities for the delivery team would require expensive CRM licences. Instead, the architect designs a compliant custom project object:

-- Conceptual SQL representing a custom project onboarding schema
CREATE TABLE Project_Onboarding__c (
    Id VARCHAR(18) PRIMARY KEY,
    Name VARCHAR(80),
    Client_Account__c VARCHAR(18), -- Relates to standard Account
    Onboarding_Coordinator__c VARCHAR(18), -- Relates to Platform User
    Target_Go_Live__c DATE,
    Project_Status__c VARCHAR(50),
    Scope_Details__c TEXT
);

In this schema, Project_Onboarding__c is a custom object that does not copy standard Opportunity fields like sales stages, forecast categories, or close probabilities. It is a delivery tracking object. Platform users can own, update, and automate this object while remaining fully compliant, saving the organisation thousands of pounds in licence costs.

A Practical Right-Sizing Mapping Playbook

The table below provides a structured mapping of standard CRM objects to compliant custom schemas, highlighting the commercial savings possible when right-sizing user assignments:

Standard Object Workarounds: Assessing Risks and Compliance Under "Indirect Access" Rules

When faced with the strict boundaries of Salesforce Platform licences, some technology teams attempt to build technical workarounds. These "hacks" are designed to expose standard CRM data to Platform users without upgrading their licences. Solutions architects must recognise that these workarounds represent a severe breach of your Salesforce agreement, exposing your organisation to high-risk commercial audits and back-licensing penalties.

Understanding the "Indirect Access" Rule

Salesforce's product terms directory defines Indirect Access as accessing standard CRM data or platform services through an integration layer, middleware (such as MuleSoft or Kafka), or custom code. The core rule is simple:

"Indirect access to the Services or platform data does not reduce the number of user licences required. Every human user who indirectly interacts with standard CRM objects must be licensed at the appropriate tier."

This means that trying to bypass a licence boundary by writing code or setting up integrations to pull standard CRM records and display them to unlicensed users is contractually a violation of the agreement.

Common Non-Compliant Workarounds and Audit Risks

Salesforce's commercial audit team uses sophisticated automated metadata scanners during platform reviews to flag licence circumvention. Key workarounds that are frequently flagged during audits include:

• Apex classes running without sharing: Writing custom Apex classes that bypass standard sharing settings to query the Opportunity table, and rendering this data to Platform users via custom Lightning components or custom API pages.
• Custom "Shadow" Objects: Setting up automated Flows or Apex triggers that copy standard Opportunity or Case records into custom objects (e.g., `Shadow_Opportunity__c`) solely to make that data visible to Platform users. This is known as "feature replication" and is a severe breach of contract.
• Email Forwarding and Slack Integration Hacks: Auto-forwarding standard Case notifications to shared queues or custom Slack channels, enabling unlicensed back-office staff to update case statuses without a standard Service Cloud licence.

Compliant Design Guidelines for Architects

To ensure absolute compliance, solutions architects should follow these simple design rules:

1. If an employee's primary role requires them to read, write, or update standard Leads, Opportunities, or Cases, they must be assigned a full CRM licence. No technical workaround is acceptable.
2. Custom objects must only be built to support net-new business processes that are not provided by standard CRM objects. Do not build custom objects that replicate standard Sales or Service Cloud functionality.
3. Ensure that your security roles, profiles, and permission sets match your contract terms. Never assign a permission set containing CRM privileges to a user assigned a Platform licence.

Migration Execution Playbook: Safely Downgrading Users Without Data Loss

Once you have identified a pool of users who are eligible for a downgrade from Full CRM to Platform licences, you must execute the transition carefully. Because Salesforce does not allow you to directly change the `UserLicenseId` on a user record, executing a downgrade requires a structured technical process to avoid metadata errors and user data loss.

The technical challenge of Profile updates

In Salesforce's data model, the user licence type is determined by the profile assigned to the user. You cannot change a user's licence directly; you must change their profile to a new profile associated with the target licence type. Once the profile is updated, the platform automatically updates the user's `UserLicenseId`. However, this update will fail if the user is still assigned permission sets, permission set groups, public groups, or queues that depend on standard CRM objects.

Step-by-Step Technical Execution Playbook

The CoE must enforce the following technical steps to execute a safe licence downgrade:

1. Step 1: Baseline Audit & Permission Set Mapping: Run a SOQL query to document all active permission set assignments for the target users. Identify any assignments that require Sales or Service Cloud privileges:

   -- Query permission set assignments for target users
   SELECT Id, AssigneeId, PermissionSet.Name, PermissionSet.License.Name
   FROM PermissionSetAssignment
   WHERE AssigneeId IN ('USER_ID_1', 'USER_ID_2')

   Remove any permission sets that depend on standard CRM objects.
2. Step 2: Resolve Metadata Hard Blocks: Check if the target users are referenced in active configurations that would block their profile update. This includes checking if the user is:
   • The sole running user of active standard dashboards.
   • The default owner of standard Lead or Case queues.
   • Referenced in active workflow rules, flow alerts, or process builders that route notifications to their account.
   Reassign these configurations to standard CRM licence holders or generic system integration accounts.
3. Step 3: Create Custom Platform Profiles: Clone your standard Salesforce Platform profile and configure the field-level security (FLS) for all custom objects. Ensure that this new profile does not contain any permissions for standard CRM tables, avoiding deployment errors.
4. Step 4: Execute the Profile Update via Apex: Update the target users' profile ID to the new custom Platform Profile. The platform will automatically handle the user licence migration behind the scenes. Below is a production-ready Apex script designed to execute this profile switch safely in bulk:

   public class LicenseDowngradeUtility {
       public static void executeProfileMigration(Map<Id, Id> userToNewProfileMap) {
           List<User> usersToUpdate = new List<User>();
           
           // Retrieve target user details
           List<User> targetUsers = [
               SELECT Id, Name, ProfileId, IsActive 
               FROM User 
               WHERE Id IN :userToNewProfileMap.keySet()
           ];
           
           for (User u : targetUsers) {
               Id targetProfileId = userToNewProfileMap.get(u.Id);
               if (u.ProfileId != targetProfileId) {
                   u.ProfileId = targetProfileId;
                   usersToUpdate.add(u);
               }
           }
           
           if (!usersToUpdate.isEmpty()) {
               try {
                   // Execute the update
                   update usersToUpdate;
                   System.debug('Successfully migrated ' + usersToUpdate.size() + ' users to new license profiles.');
               } catch (DmlException ex) {
                   System.debug(LoggingLevel.ERROR, 'DML Exception during license migration: ' + ex.getMessage());
                   throw ex;
               }
           }
       }
   }

5. Step 5: Post-migration UAT and Verification: Have the migrated users log in and complete standard processes to verify they can access Accounts, Contacts, and custom objects. Confirm that standard CRM objects (Opportunities, Cases, Leads) are completely hidden, keeping the org compliant.

Post-Migration Verification Audit Query

To verify that your migration was executed successfully and that no active platform users retain non-compliant permission set licenses, run the following query against your database:

-- Verify permission set licenses assigned to platform users
SELECT Id, Assignee.Name, PermissionSetLicense.DeveloperName
FROM PermissionSetLicenseAssign
WHERE Assignee.Profile.UserLicense.Name = 'Salesforce Platform'

This query must return zero records. If any records are returned, it indicates that a Platform user is assigned a CRM permission set licence, which violates compliance terms and must be resolved immediately.

Summary: The Path to Compliant Cost Savings

By mapping out your user base, designing compliant custom schemas, and executing profile migrations using this playbook, your Center of Excellence can right-size your Salesforce spend safely. Platform licence migrations are a highly effective way to eliminate wasted software spend while maintaining a clean, compliant, and high-performing Salesforce environment.