Skip to main content

Latest Post

Record Types & Page Layout Strategy

  Record Types & Page Layout Strategy 💬 In plain words:   Record Types let one object act like different forms for different teams. Different picklist values, page layouts, and processes — same Account object. Use them for truly different business processes. Not for cosmetic layout changes. 📌 Example:   One Account object, two businesses: 'Retail Customer' record type shows B2C picklist values and layout. 'Enterprise Client' shows contract fields and a different sales process. Same table, two costumes. 🧠 One object, many costumes:   A Record Type is a costume on the same object — different picklists and layouts, same table underneath. Concept Record Types split one object into business variants. •   Each type can carry its own subset of picklist values, its own business process — Lead, Case and Opportunity stages — and its own page layout per profile. •   Lightning has changed the calculus. Dynamic Forms and conditional comp...

User & Feature Licensing

 User & Feature Licensing

💬 In plain words:  The license is what the company PAID for — it sets the ceiling of what a user could ever do. Profiles and permission sets can only work below that ceiling. No license feature = no amount of admin setup can grant it.

Concept

The User License (Salesforce, Salesforce Platform, Experience Cloud variants, etc.) sets the ceiling of what a user can ever be granted — profiles/permission sets can only work within it. Feature Licenses (Service Cloud User, Marketing User, Data Cloud) switch on product areas per user, and Permission Set Licenses (PSLs) entitle specific permissions (e.g., Einstein/Agentforce capabilities) that a permission set can then grant. Licensing is an architecture concern because it drives cost and constrains design: an object model that forces everyone onto full Salesforce licenses is an expensive design. Connects to 1.2 (grants must fit the license) and Module 19 (AI features are PSL-gated).

Core Q&A

Q: When do you put a user on a Salesforce Platform license instead of a full Salesforce license, and what breaks if you get it wrong?

🎯 Say this first:  Platform license when the user only touches custom apps — never standard Sales/Service objects; get it wrong and their features simply don't exist.

A: Platform licenses suit users who work only with custom objects plus a limited set of standard objects (Accounts, Contacts, and a few others) — internal ops teams, approvers, report consumers. They cannot use core CRM objects like Opportunities, Leads, or Cases as first-class users, so if a 'platform' user type later needs pipeline access you face a re-licensing bill or an anti-pattern (shadowing standard objects with custom copies — a data-model smell). The architect's job is to map user types to objects early and licence to the map; getting it wrong either overspends (everyone on full CRM) or forces object-model distortions.

Follow-ups (scenario-based)

Q1: For an Experience Cloud site with 40,000 rarely-active customers and 200 heavy-use partner firms, how do you choose license models?

A1: Customers: login-based Customer Community licenses — you pay per login pool, ideal for large populations with sporadic access. Partners: member-based Partner Community licenses for the heavy daily users (member-based wins when a user logs in more than roughly a handful of times a month), and Partner (not Customer) tier because they need sharing constructs like partner roles and opportunity access. Show the interviewer you model expected login frequency before picking, since the crossover point is a cost calculation, not a rule of thumb.

Q2: An internal custom-object application becomes a team's standard tool. How does licensing shape who can use it?

A2: The platform's UI and data model are custom objects plus Flow/LWC, so the consumer user type (engineers logging tasks, leads reading delivery reports) fits Platform licenses — only the user types touching CRM data need full licenses. Agentforce/Einstein generative features are additionally gated by Permission Set Licenses, so the AI capabilities were exposed through a dedicated permission set backed by the PSL, assigned only to user types that genuinely invoke generation. That framing — custom-object product, platform-licensed consumers, PSL-gated AI — demonstrates cost-aware architecture, which is precisely what an architect round probes for.

Read this also: - Object-Level & Field-Level Security (CRUD/FLS)