Salesforce External Identity Licenses: Managing Customer and Partner Access

Salesforce External Identity Licenses

Modern enterprises often require external users, such as customers, partners, or contractors, to log in securely and use a single sign-on.

Salesforce External Identity licenses (part of Salesforce’s Customer Identity offerings) allow organizations to extend identity and access management beyond employees.

This article explains External Identity licenses, how they differ from standard Salesforce licenses or Community licenses, and how CIOs/CTOs can leverage them to cost-effectively manage customer and partner access.

We cover real-world considerations such as pricing models (including monthly active user plans), best practices for implementation, and strategies to ensure a seamless yet secure experience for external users leveraging Salesforce as an Identity Provider.

What is a Salesforce External Identity License?

A Salesforce External Identity license is a specific type of Salesforce license designed for users who are external to your company (such as customers or partners) and who need to authenticate via Salesforce.

Key points about External Identity licenses:

• Identity Services for External Users: Just like internal Identity licenses provide SSO/MFA for employees, External Identity licenses allow external users to log in, self-register, or use single sign-on without giving them a full Salesforce Community (Experience Cloud) license. These external users typically do not need to directly interact with Salesforce CRM objects; they just need a way to securely log into a Salesforce Experience Cloud site or even non-Salesforce applications using Salesforce as the identity broker.
• Customer and Partner Login Portals: External Identity licenses are often used to power login portals for customers (for example, a customer support site or an account management portal) or partners (like a partner portal or dealer portal). Instead of each customer or partner being a full Salesforce user, they get an identity that allows them to authenticate and verify themselves with MFA, and then be directed to the appropriate resources.
• Reduced Cost Option: External Identity licenses are much cheaper than external user licenses. Salesforce’s external user licensing (Experience Cloud) can be costly if you have thousands of users. External Identity licenses offer a lower-cost authentication-only alternative when the external user doesn’t need full access to Salesforce data. In some cases, pricing is not per user, but per login or per volume of active users, which can be economically efficient for large communities.
• Included Identity Features: External Identity users can leverage all the identity features: single sign-on, multi-factor auth, password self-service, social login (if configured), etc. They typically can self-register (sign up on a portal), verify their email or phone, and log in to access whatever external app or site you’ve linked. Salesforce is a mini-Identity Provider (IdP) for your external audience.

In summary, a Salesforce External Identity license allows you to manage external identities at scale through Salesforce without incurring the high costs of full community user licenses for every external person.

Use Cases for External Identity Licensing

Understanding when to use External Identity licenses versus other license types is key. Here are common use cases:

• Customer Self-Service Portals: Suppose you run a support site where customers can log in to create support tickets or check knowledge articles. You can use Customer Community licenses if that site is built on Salesforce Experience Cloud (community). However, if customers only need to authenticate, and then you perhaps redirect them to another system or a lightweight page, an External Identity license could suffice just to log them in. For example, customers log in via Salesforce Identity and are taken to an external knowledge base that trusts Salesforce’s login.
• Partner Single Sign-On: If you have a network of partners/resellers who need to access various sales tools, training portals, or a limited Salesforce data set, you might use Partner Community licenses for full access. But maybe you have a scenario where partners must SSO into a third-party partner portal (not on Salesforce) using credentials. External Identity can let partners use Salesforce credentials to log in everywhere. You could maintain a Salesforce identity directory of all partner users and let them SSO into non-Salesforce applications (like a learning management system or an ordering system), all managed under your Salesforce org’s identity.
• Consumer Login for Apps: Some companies leverage Salesforce Identity to manage consumer logins for web or mobile apps. For instance, an electronics company might allow customers to create an account (stored in Salesforce identity) to log into a mobile app that controls their IoT device. External Identity licensing, possibly combined with the Customer Identity Plus product, would be used here to handle potentially huge numbers of users at a fixed cost.
• Unified ID across Platforms: If your strategy is to give customers/partners a single account that works across multiple platforms (some on Salesforce, some external), using Salesforce External Identity as the unified IDP can simplify user account management. Users register once, and that account (their email/username) is recognized across all integrated systems via SSO. This improves user experience and centralizes user profile management in Salesforce.

In each case, the external user typically doesn’t need to use the Salesforce UI beyond a login screen or profile update page. They mainly need authentication and perhaps some basic services like self-service password reset.

Read Maximizing Value from Salesforce Identity Licenses: Cost Optimization and Best Practices.

External Identity vs. Community (Experience Cloud) Licenses

It’s important to differentiate External Identity licenses from the traditional Experience Cloud (formerly Community) user licenses:

• Experience Cloud (Community) License: This license (Customer Community, Customer Community Plus, Partner Community, etc.) allows external users to log into a Salesforce community site and interact with Salesforce objects (cases, opportunities, etc., depending on license type). These are relatively expensive if you have large numbers of users. Salesforce often prices them per login or member per month, and they grant specific access to Salesforce data. Use these when external users need to work with Salesforce records directly (for example, a partner updating leads in your Salesforce, or a customer viewing their cases/orders stored in Salesforce).
• External Identity License: This license does not grant access to Salesforce objects. The external user with this license can log in (to Salesforce’s identity layer) but will usually be redirected or allowed to access something else. Think of External Identity as a lighter-weight license for identity-only purposes. They are priced to allow scale (tens of thousands or millions of users) because the assumption is that each user is not consuming significant Salesforce data or storage.

Comparison Table:

In many cases, organizations use a combination: e.g., have a small subset of power partners with Partner Community licenses (because they work heavily in the system), but most casual partners just SSO into a learning portal using External Identity licenses.

This mix allows cost control by only paying full price for those needing full access.

Pricing Models and Real-World Cost Considerations

Salesforce External Identity (also branded as Salesforce Customer Identity in some contexts) is often sold in packages based on usage rather than a strict per-user fee:

• Monthly Active Users (MAU): A common model charges a fixed price for a block of monthly active users. For example, one Salesforce offering is around USD 24,000 annually for up to 25,000 monthly active users. This means that, at that price, you can have up to 25k different external users logging in each month. If you exceed that, you move to a higher band (or pay more). This model is great for consumer-facing scenarios where you might have a large user base, but not all are active every single month, or you want predictable costs at scale.
• Login-Based Pricing: In some cases, Salesforce may allow login-based pricing (similar to community logins). For instance, you pay per login (with maybe bulk packs), for example, $X per 100 logins. This could be economical if your users log in infrequently (say, customers only log in once a quarter).
• Included vs. Add-On: Check if your current licenses include External Identity rights. Sometimes, higher-tier community licenses come with several External Identity uses. However, typically, External Identity is an add-on purchase. It might come in editions like “Customer Identity” or “Identity for Employees/Customers,” with different internal and external pricing.
• Negotiation is Key: As with any Salesforce product, the list prices are often negotiable. External Identity is a newer area, and Salesforce is competing with established identity providers to meet your external identity needs. If the sticker price is high, discuss your user volumes and consider multi-year commitments to bring it down. Also, suppose you’re already a big Salesforce customer. In that case, you can push for accommodations (e.g., “we will put our customer identity on Salesforce, but we need a flat rate reasonable for up to 50k users”).
• Cost vs. Benefit: The benefit of using Salesforce for external identity is seamless integration if you already use Salesforce for CRM – one less platform to manage. But you should still compare the cost against other options. For instance, if Salesforce wants $50k/year for external identity and you have a quote from Okta Customer Identity or AWS Cognito that’s less, that’s leverage to negotiate. Many companies find Salesforce’s External Identity cost-effective, especially if they factor in the saved development effort of using built-in Salesforce identity features (self-service registration flows, etc., which would otherwise have to be built on another platform).

To avoid surprises, always clarify:

• Will external identities count towards my org’s user limit or storage? (They’re generally not for storage, and they’re counted separately from internal licenses.)
• Are there charges for SMS verification messages or high-volume identity verification usage? (Salesforce does have “Identity Verification Credits” for SMS OTP—often, some amount is included, but heavy use might incur add-on costs.)

Implementing External Identity: Best Practices

When rolling out Salesforce External Identity for customer or partner access, consider these best practices:

• Custom Branded Login and Registration: Use Salesforce’s Experience Cloud to create a login page or use My Domain and branding to give external users a familiar experience. You can create a custom login page (for example, login.yourcompany.com) powered by Salesforce but skinned with your branding. For registration, Salesforce provides options for self-registration in communities – tailor those to capture the fields you need for a new user (name, email, account number, etc.).
• MFA and Security Settings: External users should also adhere to security best practices. Enable multi-factor authentication for external identity users as appropriate. Salesforce allows you to enforce MFA for external users via Salesforce Authenticator, SMS, or email OTP. Since external users might reuse passwords, MFA is an important safeguard for your portals.
• Profile and Access Management: Even though External Identity users don’t access standard objects by default, you will still manage them via Salesforce profiles or permission sets to some extent. For example, if the external user is going to log into an Experience Cloud site (even just to see a welcome page or be redirected), they need a profile. Typically, Salesforce provides a default “External Identity User” profile. Ensure this profile has the correct settings, e.g., allow them to use certain connected apps, and perhaps grant them access to an Experience Cloud site if needed for the login handshake.
• Connected Apps and SSO Config: Many implementations involve Salesforce as the IdP and another system as the service provider. Set up Connected Apps in Salesforce for each external application you want to allow SSO to enter. For instance, if customers should be redirected to an e-commerce site after logging in, configure a SAML/OIDC connected app for that e-commerce site. Test the SSO flow thoroughly: The user comes to Salesforce login, authenticates, and then lands in the other application without needing to log in again.
• Self-Service Account Management: External users must inevitably reset passwords, change email, etc. Leverage Salesforce’s self-service features:
  • Enable the “Forgot Password” flow on the login page so they can reset passwords automatically.
  • Consider enabling self-service update pages where users can update their profile info (you can expose this via a simple Experience Cloud page that writes to their Contact record or identity user record).
  • If it’s a partner user base, you might integrate approval processes – e.g., a partner manager must approve new partner registration, which Salesforce can handle via flows.
• Scale Testing: If you plan to have many external users, do some testing or get assurances from Salesforce on capacity. Salesforce can handle large identity volumes (especially if using the MAU model, which presumes high scale). Still, you want to optimize login flows, registration, and connected app responses. Monitor authentication times for users in different regions if you have a global audience – consider using Salesforce’s infrastructure, like deploying your identity site on a Salesforce org close to your user base, or using a CDN for assets.
• Data Storage for External Users: External Identity users are often tied to a Salesforce Contact or Person Account in your CRM (especially if they self-register on a community, it typically creates a Contact under some Account). Plan how you will organize these. For customers, you might create a generic account like “Self-Registered Customers” to hold these contacts, or better yet, have them link to actual customer accounts if you know the company they belong to. Efficient data organization ensures you can later leverage that info (say, link a case to a customer’s contact if they logged in). Keep an eye on the volume because millions of users = millions of contact records, potentially affecting storage. However, Salesforce usually offers high-volume user storage solutions, or these records may not count the same way – clarify this in your planning.

Security and Compliance Considerations

Bringing potentially tens of thousands of external identities into your Salesforce org means security is paramount:

• Isolation: External Identity users should have very restricted permissions in Salesforce—typically, they won’t have any access to internal data. Make sure profiles for external identities have no visibility on internal objects. Use something like the “Identity User” license type, which by default has no CRM privileges. Also, consider using separate Experience Cloud sites or identity portals to logically segregate external login flows from internal ones.
• Regulatory Compliance: If your external users are consumers, consider privacy regulations (GDPR, CCPA, etc.). Salesforce provides tools to support consent management and data deletion for personal data. Ensure your implementation collects consent where needed (e.g., a checkbox at registration agreeing to terms and data usage) and that you have processes to delete or anonymize user data if a consumer requests it. The External Identity implementation should integrate with your compliance procedures, possibly storing minimal personal data.
• Audit and Monitoring: Leverage Salesforce’s event monitoring or at least login history to track external user login attempts, failures, etc. Since external users might be targets for credential stuffing or other attacks, monitor for suspicious login patterns (many failed attempts could indicate a brute force attack). Salesforce Shield’s Event Monitoring (if you have it) can give detailed logs on authentication events, which could be piped into a SIEM (Security Information and Event Management) system for analysis.
• Support & User Assistance: External users will forget passwords or have login issues. Set up a support plan: perhaps create a dedicated support page or chatbot for login help. Internally, have your help desk prepared to handle external identity issues. For example, they might need the ability to send a password reset link or verify the user’s identity by other means if needed. A smooth support process will ensure the external user experience remains positive even when issues arise.

By addressing these considerations, enterprises can confidently use Salesforce External Identity licenses to provide customers and partners with a secure and user-friendly login experience while controlling costs.

Recommendations

• Segment Your External Users: Analyze the needs of different external user groups. Use External Identity licenses for large groups of users who only require authentication and basic profile access. Reserve full Community/Partner licenses for those needing to interact with Salesforce data. This tiered approach minimizes license costs while meeting all users’ needs.
• Adopt a Scalable Pricing Model: Choose a pricing model that fits your user activity pattern. If you have thousands of customers but only a fraction of the monthly log-ins, negotiate a monthly active user-based plan. This ensures you’re not overpaying for dormant accounts and can handle growth economically.
• Integrate with Your IAM Strategy: Treat Salesforce External Identity as a broader Identity and Access Management (IAM) strategy component. Ensure it integrates with your Single Sign-On architecture. For instance, if your enterprise uses an IdP like Azure AD for workforce SSO, you can still use Salesforce as the IdP for customer identities, but consider how those systems might connect or remain separate. A cohesive strategy prevents identity silos and security gaps.
• Customize the User Experience: Leverage Salesforce’s tools to provide external users a smooth, branded login experience. Use custom domains, branded login pages, and easy self-service features. A frictionless experience (e.g., social login options, simple registration) will encourage user adoption and reduce support calls.
• Enforce Security Best Practices: Do not skimp on security for external identities. Enable MFA for customer and partner logins where appropriate, especially for sensitive applications. Regularly review external user permissions to ensure they remain minimal (“least privilege” principle). Keep your identity site updated with the latest security patches and Salesforce releases.
• Monitor Usage and Adjust: Continuously monitor external login metrics. Track how many users log in, how often, and peak usage times. This will help in capacity planning and optimizing your license model (for example, if MAUs consistently stay well below your cap, you might renegotiate a lower tier; if they’re spiking, ensure you’re covered to avoid access issues). Use these insights to improve the system (e.g., if many users fail to log in at step X, maybe improve instructions or UI there).
• Leverage Salesforce Customer Identity Features: If you purchased the Salesforce Customer Identity product (which includes External Identity capabilities, often with Identity Plus), use its full feature set. This can include Progressive Profiling (gradually collecting more info on users), social sign-on (letting users log in with Google/Facebook, etc., which Salesforce can manage), and built-in user identity verification tools. Extracting all these features increases the ROI of your license spend and enhances user satisfaction.
• Plan for Lifecycle Management: Plan for the user lifecycle of external identities. For example, if a partner leaves their company, how will you deactivate or archive their account? Implement automated jobs or reviews to deactivate external identities that haven’t been used in 12 months (if appropriate). This is good security hygiene and could keep your “active user” counts and costs under control.
• Test Extensively Before Launch: Run a pilot or beta with a small group before rolling out to all customers or partners. Test the registration, login, MFA, and SSO flows thoroughly. Ensure the system can handle the load, and the user instructions are clear. It’s easier to tweak the process with a small group of friendly users than to fix issues after 50,000 customers face a problem.
• Communicate to External Users: If introducing a new login system or requiring existing users to move to Salesforce-based login, communicate early and often. Provide clear guides or FAQs to your customers/partners on how to sign up or transition their accounts. Emphasize improvements (security, single sign-on convenience) to get buy-in. This reduces resistance and confusion, making your external identity rollout more successful.
• Evaluate ROI Periodically: Periodically assess if using Salesforce External Identity delivers value. Compare the costs and benefits: e.g., has it reduced IT overhead for managing separate login systems? Is customer engagement better due to easier logins? Ensure that the chosen licensing model still aligns with usage; you might need to adjust your contract if, for example, your active users doubled (the success of your product might mean renegotiating a higher tier, ideally with some volume discount). Being proactive keeps the solution cost-effective in the long run.

FAQ

Q1: Can external users with an External Identity license access a Salesforce Experience Cloud site (community)?
A: They can access a community only in a very limited way – essentially by logging in or seeing a basic landing page. External Identity licenses do not grant rights to view or interact with standard objects or records in a community. You need a Community license if you want an external user to fully use a community (see cases, contribute to feeds, etc.). However, you could use an External Identity license to let a user log in on a community page and immediately redirect them to an external site or perhaps show them content that doesn’t require a community license. In short, an external identity is for authentication, and a community license is for authentication and data access.

Q2: What exactly is Salesforce Customer Identity about External Identity licenses?
A: Salesforce Customer Identity is a product offering encompassing the features needed to manage external identities (like customers or partners) at scale. When you buy Salesforce Customer Identity, you essentially buy the rights to use External Identity licenses and the associated features (often, this includes Identity Plus capabilities such as advanced identity configuration). It often comes in edition form, e.g., “Customer Identity Plus,” which might align with the Identity Plus license for external use. In practice, you might not see “External Identity” listed on an order form; instead, you’ll see something like “Customer Identity (25k MAU pack)”. However, as a day-to-day admin, you will assign users the External Identity license type in Salesforce. So, Customer Identity = product name, External Identity = actual license assigned to users.

Q3: How do I assign an External Identity license to a user?
A: In Salesforce setup, external users (like those who self-register via a community) will be created with a certain user license. You can manually create an external user by going to an Account > Contacts > Enable as Customer User (if using communities). When doing so, if you have an External Identity available, it will show up as an option for the User License on the user creation page. Typically, you would choose “External Identity” as the license and then an appropriate profile (like External Identity User profile). If users are self-registering, Salesforce can be configured to automatically assign the External Identity license to them upon registration (this is done via your Experience Cloud site settings and registration configuration). You’ll want to ensure you have available External Identity licenses (or unlimited MAU if that’s your model) so new registrations can occur without admin intervention.

Q4: Is there a limit to how many external identities I can have?
A: Generally, Salesforce can support many external identity users, especially if you are on a MAU-based plan. The practical limits might involve performance or data storage considerations, but Salesforce designed these licenses for potentially millions of users. If you anticipate an extremely large user base (hundreds of thousands or more), discuss with Salesforce to ensure your org is configured (they might enable something like High Volume Customer Contacts optimized for scale). There might also be API limits to consider if many users log in simultaneously (for instance, if you have a global event where many users log in simultaneously). But licensing-wise, if you pay, e.g., 100k MAUs, you should be able to register at least that many users (and usually more, since not all will be active concurrently). Always architect for scale if you expect it – e.g., load test the login flow.

Q5: How does Salesforce count a “monthly active user” (MAU) for Customer Identity licensing?
A: A monthly active user is a unique user who authenticates in a given calendar month. For example, if the same user logs in 10 times a month, they still count as one MAU. If they don’t log in that month, they count as zero for that month’s tally. Salesforce will likely track the number of unique external identity users logged in during the past 30 days. You can see the MAU count on some dashboards or usage metrics they provide to you. If you consistently exceed your purchased MAU tier, your Salesforce rep will usually approach you to uplift your license to the next band. It’s good to track this on your side too. Note: If you have multiple communities or sites, check if the MAU covers all combined or per site (usually combined per org/Identity license purchase).

Q6: Can we use Salesforce External Identity for internal employees as well?
A: Technically, you could assign an employee an External Identity license if you wanted them treated as an external user in an Experience Cloud. But generally, you would use the normal Identity licenses (internal) for internal workforce SSO. External Identity is meant for users who are not internal employees and are often tied to contact records. There are also some differences in managing them – for example, external identities might use the High Volume Customer Contact model. Keeping internal and external identity management separate for clarity and security is best. Use internal Identity licenses for workforce SSO needs, and External Identity for customer/partner needs.

Q7: How does an External Identity user differ from a Community user regarding the Salesforce data model?
A: In Salesforce’s data model, an external user (community or identity) is associated with a Contact on an Account (unless you use Person Accounts or a special identity-only user type). Community users’ contact information usually links to an account representing their company (for partners), a generic account, or their account (for customers). External Identity users are similar – they will often exist as contacts under an account (which could be a generic “External Identity Account” or grouped by some affiliation). One difference is that High-Volume Customer Users (which External Identity likely uses) do not have roles in the role hierarchy and are designed for scalability. They can’t own records; they typically have some sharing limitations (which is fine, since they don’t need to own records if they aren’t accessing objects). In practical terms, you, as an admin, will see external users in the Users list with License = External Identity. They’ll have a contact record in the background. But they won’t participate in things like sharing rules the same way a Community Plus user might.

Q8: Do External Identity users need to be manually linked to Contacts and Accounts?
A: If you use Salesforce self-registration or enable an account’s contacts to be users, Salesforce will link the new user to a contact record. You usually need a contact for each external user to exist (or be created). In self-registration settings, you often specify a default Account where new Contacts will be created if they register. For example, you might have an account called “Customer Portal Self-Registrations” – every new user who signs up gets a Contact under that account, and then a User linked to that contact. Suppose your external users are part of known organizations (partners). In that case, you might instead create accounts for each partner and have an internal manager or a registration process assign new user contacts to the correct account. It depends on your data and how you want to organize external users. The key is, yes, there is typically a contact link, but Salesforce can automate much of it via the Experience Cloud configuration.

Q9: What happens if an external user tries to access something they’re not licensed for?
A: If an External Identity user somehow attempts to access a Salesforce page or data requiring a higher license (by typing in a Salesforce record URL), they will simply get an error or lack of access. They might see an “Insufficient Privileges” message. Since their profile has no object permissions, they won’t even see those tabs or options normally. Essentially, the system will prevent them from doing anything beyond what they’re meant to. From a design perspective, you should ensure your community pages or login flows don’t direct these users to unauthorized areas. For example, don’t put an internal Salesforce link on an external portal page. Keep their experience siloed to the intended SSO or portal usage.

Q10: Is there any overlap between External Identity and other Salesforce products like Commerce Cloud or Marketing Cloud?
A: Good question. Salesforce has various clouds, each with its way of dealing with users. For instance, Commerce Cloud (B2C) might have its own customer accounts concept, and Marketing Cloud has subscriber lists, etc. Salesforce has been working on connecting these under Customer 360 Identity. If you use Salesforce’s B2C Commerce or other cloud services and want one unified login for customers, an external identity (Customer identity) can often serve that purpose via something called Salesforce Identity for customers across clouds. Essentially, you’d authenticate the user via Salesforce Identity and then pass that to Commerce Cloud, etc. It might require some integration work or products like Identity for B2C. If you’re heavily invested in multiple Salesforce clouds, you should discuss the best approach with Salesforce so that you don’t end up with siloed user accounts in each cloud. The goal of Customer Identity is to unify that. It may involve additional connectors or use something like MuleSoft for token exchange. But from a licensing perspective, you’d still be looking at External Identity licenses in your core Salesforce org serving as the primary IdP.

Read more about our Salesforce license management service.

Do you want to know more about our Salesforce License Management Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit