Salesforce Applications: Apps Guide | SalesforceTutorial

Salesforce applications are the apps users open in Salesforce, the packaged solutions installed from AppExchange or AgentExchange, the custom Lightning apps admins build in App Manager, and the connected apps that let external systems use Salesforce APIs. Use the right meaning before you install, integrate, or govern an app.

This guide explains applications in Salesforce from an admin and architect view: what they are, how AppExchange packages differ from connected apps, what apps can you connect with salesforce, and how to review third-party apps without creating security or support problems.

What are Salesforce Applications?

Salesforce applications are not one feature. In production orgs, the term covers four layers that often overlap.

Salesforce Help describes Lightning apps as containers that can include standard objects, custom objects, and tabs. That means a Lightning app controls a user workspace, not only a menu. See the official Salesforce Help page for Lightning apps.

How Salesforce Applications Work in an Org

Most Salesforce applications are metadata-driven. A package can add objects, fields, permission sets, Lightning pages, flows, Apex classes, custom metadata, named credentials, scheduled jobs, and tabs. A Lightning app exposes selected items to users. A connected app authorizes an external client to authenticate and call Salesforce APIs.

Applications in salesforce: app, package, connected app, and integration

The phrase applications in salesforce should be clarified in every design note. A Lightning app is a user workspace. A managed package is vendor-maintained metadata with an upgrade path. An unmanaged package copies metadata into your org and makes your team the owner. A connected app is a trust and authorization configuration for OAuth, SAML, or OpenID Connect. A custom-built app is your own metadata and code.

Salesforce Applications on AppExchange and AgentExchange

The Salesforce marketplace is where admins find many packaged Salesforce applications. Salesforce now presents AppExchange as AgentExchange on the public marketplace, so older notes may say AppExchange while current marketplace pages may say AgentExchange. Treat the marketplace name as current branding and review the package details before you rely on any app.

Salesforce appexchange number of apps 2025

For salesforce appexchange number of apps 2025, do not copy a stale number into an architecture document. Salesforce’s live marketplace count can include agents, apps, tools, experts, and other vetted listings, while some official collection pages count apps and certified consulting organizations differently. Record the date checked and use the official Salesforce marketplace for the current count.

List of salesforce administratio 3rd party apps for admin review

The query list of salesforce administratio 3rd party apps usually means administration-focused third-party apps. Review categories before brands: admin and developer tools, backup and restore, data quality, DevOps, impact analysis, documentation, adoption guidance, forms, document generation, telephony, and finance connectors. For each category, ask what metadata it reads, what records it writes, whether data leaves Salesforce, how it authenticates, and who owns support.

What apps can you connect with salesforce

The answer to what apps can you connect with salesforce depends on the integration pattern. Email, calendar, ERP, billing, data warehouse, analytics, telephony, messaging, identity, portal, and internal web apps can connect when they use a supported API or connector. The safe pattern may be an AppExchange package, OAuth connected app, REST API, Bulk API, MuleSoft flow, External Services action, named credential callout, or Agentforce action with human approval.

How to Evaluate Salesforce Applications Before Installing

Do not treat Salesforce applications as harmless add-ons. A package can change your data model, run automation, add Lightning components, create scheduled jobs, or authorize an external service. Use the same release discipline you apply to custom development.

• Fit: Start with the business process, record ownership, support owner, and reporting need. Avoid buying an app for a process that standard Salesforce configuration can support.
• Package type: Managed packages are usually vendor-supported and upgradeable. Unmanaged packages are copied into your org and should be treated as local metadata.
• Permissions: Install for admins only first, then assign permission sets or permission set groups by persona.
• OAuth: For connected Salesforce applications, document scopes, permitted users, session policy, token policy, and integration owner.
• Data movement: Confirm whether Salesforce data stays in the org, moves to a vendor system, or is replicated into another platform.

Trailhead’s official AppExchange unit explains managed and unmanaged package behavior and install planning. Use Install AppExchange Packages when training admins on safe installation.

Run a package license inventory query

For managed packages, the PackageLicense object helps admins review allowed and used licenses. Salesforce’s object reference lists PackageLicense for managed package license information and notes availability from API version 31.0 and later.

SELECT NamespacePrefix, AllowedLicenses, UsedLicenses, ExpirationDate, Status FROM PackageLicense ORDER BY NamespacePrefix

Run this query as an admin or setup integration user. Use the result during renewal reviews and access cleanup.

How to Install and Govern Salesforce Applications

For packaged Salesforce applications, Salesforce Help states that installing packages requires the Download AppExchange Packages permission. Keep that permission with a small admin group.

1. Test in a sandbox that has realistic users, permissions, data, and automation.
2. Read the listing, package type, edition support, latest release date, required licenses, and security notes.
3. Install for admins only before opening access to business users.
4. Assign package permission sets through role-based permission set groups.
5. Review flows, Apex triggers, scheduled jobs, platform events, outbound messages, and external callouts.
6. Test with sales user, service user, manager, integration user, and read-only auditor personas.
7. Document rollback: uninstall, disable, remove permissions, retain data, or archive records.

Best Practices for Salesforce Applications in Enterprise Orgs

Every app needs an owner, access model, data classification, renewal date, and removal plan. Without those five items, Salesforce applications become unknown risk over time.

Create an application register

Track namespace, vendor, business owner, technical owner, install date, sandbox test date, connected app name, OAuth scopes, API user, data categories, renewal date, and support contact.

Use least privilege

Do not let Salesforce applications rely on System Administrator access. Assign only the package permissions and object permissions users need. For integrations, prefer a dedicated integration identity and reviewed OAuth scopes.

Measure load after installation

Some third-party Salesforce applications poll APIs, run bulk jobs, or update parent records. Watch API usage, async jobs, failed flow interviews, debug logs, and record-locking errors after installation.

Apex Pattern for Connected Salesforce Applications

When a custom Salesforce app calls an external service, use a named credential instead of hardcoding endpoints, secrets, or tokens. Salesforce Developer documentation states that named credentials define the callout endpoint and authentication parameters. See the official Named Credentials Developer Guide.

public with sharing class ExternalOrderStatusClient { public class OrderStatusException extends Exception {} public static Map<String, Object> getStatus(String externalOrderId) { if (String.isBlank(externalOrderId)) { throw new OrderStatusException('External order ID is required.'); } String encodedId = EncodingUtil.urlEncode(externalOrderId, 'UTF-8'); HttpRequest request = new HttpRequest(); request.setEndpoint('callout:Order_Status_API/v1/orders/' + encodedId); request.setMethod('GET'); request.setTimeout(10000); HttpResponse response = new Http().send(request); if (response.getStatusCode() == 200) { return (Map<String, Object>) JSON.deserializeUntyped(response.getBody()); } if (response.getStatusCode() == 404) { return new Map<String, Object>{'found' => false}; } throw new OrderStatusException('Order status service returned HTTP ' + response.getStatusCode() + '.'); } }

Governor limit note: do not call this pattern once per record from a trigger. Use Queueable Apex, batching, platform events, or another bulk-safe pattern for multi-record work.

Secure SOQL and DML used by custom apps

Custom applications in Salesforce often expose data through Apex controllers. For user-facing code, enforce object and field permissions. Salesforce recommends user-mode database operations for CRUD and field-level security enforcement in Apex.

public inherited sharing class AccountWorkspaceService { @AuraEnabled(cacheable=true) public static List<Account> getRecentAccounts() { return [SELECT Id, Name, Phone, LastModifiedDate FROM Account WITH USER_MODE ORDER BY LastModifiedDate DESC LIMIT 20]; } @AuraEnabled public static void updatePhone(Id accountId, String phone) { if (accountId == null) { throw new AuraHandledException('Account ID is required.'); } Account accountToUpdate = new Account(Id = accountId, Phone = phone); Database.update(accountToUpdate, AccessLevel.USER_MODE); } }

Common Errors with Salesforce Applications

How Salesforce Applications Relate to Other SalesforceTutorial Topics

Application decisions touch data, security, reporting, and integrations. Review Salesforce products and platform clouds, Salesforce Data Cloud architecture, Salesforce telephony integration patterns, Salesforce reports and dashboards, and Salesforce Data Loader for admin data operations.

Frequently Asked Questions