Salesforce News

When sending emails from Salesforce Flow, you can use an Organization-Wide Email Address as the sender. Although Organization-Wide Email Addresses configured for User Selection appear in the list of available options, the Default No-Reply Address doesn’t appear in the list. You might think that you need to change the purpose of the Org-Wide Email Address to make it available in Flow. However, that’s not necessary. Fortunately, there is a workaround that allows you to use the existing Default No-Reply Address without changing its configuration. Let’s see how it works. Why Is the Default No-Reply Address Missing in Salesforce Flow? In Salesforce, you can configure Organization-Wide Email Addresses with different purposes: User Selection: Allows users with the appropriate permissions to select the email address when sending emails. Default No-Reply Address: Used for certain automated system notifications, such as case-related emails. User Selection and Default No-Reply Address: Makes the address available for both purposes. When configuring the Send Email action in Salesforce Flow, you can set the Sender Type to OrgWideEmailAddress and choose an address from the available options. However, if your Org-Wide Email Address is configured exclusively as Default No-Reply Address, it won’t appear in the available options. Salesforce intentionally restricts user selection of addresses configured for this special purpose. One possible solution is to change the purpose to User Selection and Default No-Reply Address. But what if you want to keep the existing configuration? How to Use the Default No-Reply Address in Salesforce Flow The solution is surprisingly simple: Instead of selecting the email address from the dropdown, enter it manually. Follow these steps: Add an Action element. Search for and select Send Email. Configure the recipients and email content. Under the sender configuration, set Sender Type to OrgWideEmailAddress. In Sender Email Address, instead of selecting an address from the available list, manually enter your Default No-Reply Address. Alternatively, you can create a Text resource containing the email address and use it in the Sender Email Address field. That’s it! Manually entering the address works even though Salesforce doesn’t offer it in the dropdown. Is This an Officially Supported Salesforce Feature? Salesforce’s official Send Email Action documentation explains that you can use a Text resource to specify an Org-Wide Email Address that isn’t available in the list. However, Salesforce doesn’t explicitly state that this also works with addresses configured exclusively for Default No-Reply use. Therefore, the behavior demonstrated here should be considered a tested workaround rather than a Salesforce-documented exception. Before using it in production, test it in your own Salesforce org, including the context in which the Flow will run. Frequently Asked Questions Can I use a Default No-Reply Address in Salesforce Flow? Yes, Send Email action successfully uses an Org-Wide Email Address configured as Default No-Reply Address when the address is entered manually in the Sender Email Address field. Why doesn’t my Default No-Reply Address appear in the Flow dropdown? Salesforce restricts user selection of Org-Wide Email Addresses configured exclusively for Default No-Reply use. As a result, these addresses might not appear among the available sender addresses in Flow. Do I need to change the Org-Wide Email Address purpose? No. The email is sent successfully without changing the address purpose from Default No-Reply Address to User Selection and Default No-Reply Address. Can I use a Text resource for the Sender Email Address? Yes. Salesforce supports providing an Org-Wide Email Address through a Text resource in the Send Email action. Conclusion If your Default No-Reply Address doesn’t appear in the sender dropdown of Salesforce Flow’s Send Email action, you may not need to change its configuration. As demonstrated above, manually entering the Org-Wide Email Address can allow the Flow to send emails using the existing Default No-Reply Address, without changing its purpose. It’s a small workaround that can save time and avoid unnecessary configuration changes. Just remember to validate the behavior in your own Salesforce org before relying on it in production. The post How to Use the Default No-Reply Address in Salesforce Flow appeared first on Salesforce Time.

Salesforce introduced a new resource type called Collection Filter Criteria in the Winter ’27 release. At first glance, it might look similar to two existing Flow elements: Collection Filter and Collection Sort. After all, it allows you to filter and sort records based on specific criteria. However, Collection Filter Criteria works differently from these elements and offers some interesting possibilities. Although it might not be useful in every scenario, it can simplify your Flows and reduce the number of elements needed in certain cases. In this post, we’ll explore how Collection Filter Criteria works, how it differs from Collection Filter and Collection Sort, and when you should consider using it in your Flows. How to Use Collection Filter Criteria Unlike Collection Filter and Collection Sort, Collection Filter Criteria is a resource type, not a Flow element. This means you won’t find it in the list of available elements or see it directly on the Flow canvas. Instead, you can create it from the Manager tab by clicking New Resource and selecting Collection Filter Criteria as the resource type. The resource allows you to define filtering and sorting criteria for an existing collection. You can then reference it in an Assignment element to retrieve the matching record. However, there is an important limitation: Collection Filter Criteria currently returns only the first matching record, not a collection of records. Even if multiple records match your criteria, the resource returns a single record based on the configured filters and sorting order. This behavior has been confirmed by the Salesforce product team as a current limitation. Therefore, Collection Filter Criteria is not a direct replacement for the existing Collection Filter element, which returns all matching records. Despite this limitation, the ability to combine filtering and sorting to retrieve a specific record can be useful in scenarios where you only need one record from a collection. Example If you follow Salesforce Flow best practices and avoid using Get Records inside a Loop, you might be familiar with this challenge. In some scenarios, you already have a record collection and need to find a specific record within it. You can use the Collection Filter element to find the matching record, but there’s a catch: even if only one record matches your criteria, Collection Filter still returns a record collection. Since the output is a collection, you cannot directly access the fields of the matching record. Instead, you need to extract the record first, which often means adding another Loop element inside your existing Loop. For example, consider a Screen Flow that allows users to select multiple Accounts and enter additional information to create multiple Case records at once. The Account lookup component returns only the selected Account IDs and names, not their other fields. If you need additional fields from the selected Accounts, you can retrieve all the Account records using a single Get Records element outside the Loop. Then, as you iterate through the repeater items, you need to find the corresponding record in the collection. Previously, you could use Collection Filter to find the matching Account, but because it returns a collection, you would need an additional Loop to extract the record and access its fields. This is where Collection Filter Criteria becomes particularly useful. Since it returns a single matching record, you can access its fields directly without adding another Loop element. You no longer need additional Loop or Assignment elements. Simply use the output of Collection Filter Criteria and continue with your Flow. Conclusion Collection Filter Criteria is a useful addition to Salesforce Flow in the Winter ’27 release. Although it currently returns only the first matching record, this limitation doesn’t make it any less valuable in scenarios where you need to find a specific record within a collection. By combining filtering and sorting in a single resource, you can simplify your Flows, eliminate unnecessary Loop and Assignment elements, and keep your canvas cleaner. Salesforce also claims that it is over 200 times faster than filtering records using Loop elements. It also supports filtering through child relationships, including Apex-defined data types, making it useful for more complex scenarios. This new resource type doesn’t replace the existing Collection Filter and Collection Sort elements, but it provides another option for working with collections more efficiently. Understanding when to use each approach can help you build cleaner, more maintainable, and better-performing Flows. The post Collection Filter Criteria Resource in Flow appeared first on Salesforce Time.

Salesforce is retiring the OAuth 2.0 Username-Password Flow on February 20, 2027. If your integrations still use this authentication method, they may stop working when Salesforce enforces the change. The biggest concern is that these failures may go unnoticed. A scheduled integration could stop updating Salesforce records without displaying any obvious warning. This is why reviewing your integrations before the deadline is essential. Here is how to identify affected integrations, migrate to a supported authentication flow, and prevent unexpected failures. When Will Salesforce Retire the OAuth Username-Password Flow? Salesforce will enforce the retirement on February 20, 2027. Salesforce first announced the change in Spring ’26 and originally planned to enforce it with Winter ’27. They later postponed enforcement to February 20, 2027, around the Spring ’27 release. You can review the release update directly in Salesforce: Open Setup. Search for Release Updates. Find Retirement of OAuth 2.0 Username-Password Flow for Connected Apps. Review the available testing and activation instructions. If you don’t see this release update, Salesforce indicates that your org already blocks the username-password flow. Salesforce also blocks this flow in orgs created in Summer ’26 and later. This is a breaking change, not just a deprecation notice. Integrations that still use the retiring flow will fail when they request new access tokens after enforcement. What Is the OAuth Username-Password Flow? The OAuth 2.0 Username-Password Flow lets an external application authenticate to Salesforce by sending a user’s credentials directly to Salesforce. The integration typically stores: Client ID (Consumer Key) Client Secret (Consumer Secret) Salesforce Username Salesforce Password Security Token, when required The application sends these credentials to Salesforce’s OAuth token endpoint. For example: curl –request POST https://login.salesforce.com/services/oauth2/token –data-urlencode “grant_type=password” –data-urlencode “client_id=YOUR_CLIENT_ID” –data-urlencode “client_secret=YOUR_CLIENT_SECRET” –data-urlencode “username=integration@example.com” –data-urlencode “password=YOUR_PASSWORD_AND_SECURITY_TOKEN” If Salesforce accepts the credentials, it returns an access token. The integration then uses that token to call Salesforce APIs. Many developers chose this flow because it was simple. It didn’t require a browser-based authorization process or certificate management. However, this simplicity creates security risks. External applications must store Salesforce passwords, which increases the risk of credential exposure. Password changes, account lockouts, and security-token resets can also interrupt integrations. The flow doesn’t support refresh tokens or OAuth scopes, and it bypasses the modern interactive MFA authentication process. Salesforce wants integrations to use more secure OAuth authentication methods instead. How to Find Integrations Using the Username-Password Flow Salesforce provides several ways to investigate OAuth authentication activity. 1. Check Salesforce Login History Start with Salesforce Login History. Navigate to Setup → Login History. Click Create New View. Enter a name such as OAuth Username-Password. Under the filter criteria, select Login Subtype. Set the operator to equals. Select OAuth Username-Password. Add Login Subtype to the displayed columns. Save the view. The Application column can help you identify which external system uses the flow. Sometimes, however, the application name won’t clearly identify the integration. You may need to check the integration user, source IP, or external system configuration. Important: Salesforce Login History generally retains six months of data, and custom views can display up to 20,000 records. An integration that hasn’t authenticated during that period won’t appear in the available records. Therefore, finding no matching records doesn’t guarantee that your org has no affected integrations. 2. Review Connected Apps Next, open Setup → App Manager. Review the Connected Apps that your integrations use. For each application, identify its purpose, owner, integration user, and authentication method. You can also open Setup → Connected Apps OAuth Usage. However, there’s an important limitation:Salesforce doesn’t display username-password flow integrations in Connected Apps OAuth Usage, even when those integrations have active sessions. 3. Search Your Integration Configurations Review the authentication settings in your middleware platforms, custom applications, scripts, and integration repositories. Look for: OAuth Username-Password Resource Owner Password Credentials (ROPC) Password Grant grant_type=password Salesforce username and password together with Client ID and Client Secret For custom code, search for: grant_type=password You can also search for requests to: /services/oauth2/token Keep in mind that several OAuth flows use this endpoint. The endpoint alone doesn’t identify the retiring flow. Check the grant_type parameter to confirm the authentication method. If the application sends grant_type=password, you need to migrate it. 4. Check Managed Packages and Third-Party Applications Don’t limit your investigation to integrations that your development team built. Third-party applications and managed packages may also use the retiring flow. In some cases, the vendor manages the authentication code, so you cannot change it yourself. In those cases, contact the vendor and ask: Does your application use Salesforce OAuth Username-Password Flow? Will the application support the February 20, 2027 retirement? Does it support OAuth Client Credentials, Web Server with PKCE, or another supported flow? Do we need to install an update? Do we need to change any Salesforce configuration? Don’t assume that an installed managed package automatically supports the new authentication requirements. Which OAuth Flow Should You Use Instead? Salesforce recommends different authentication methods for different integration architectures. OAuth Flow Recommended Use Case User Interaction Client Credentials Server-to-server integrations, middleware, scheduled jobs, and data synchronization No Web Server with PKCE Applications that authenticate individual users Yes, during initial authorization JWT Bearer Certificate-based server-to-server integrations No interactive login required For many server-to-server integrations, OAuth Client Credentials offers the simplest replacement. However, you should choose the flow based on the application’s requirements. For example, if an application must access Salesforce using each user’s permissions, Client Credentials may not work because Salesforce executes requests under a configured Run As user. How to Migrate to OAuth Client Credentials Flow The OAuth Client Credentials Flow lets an application authenticate with its Client ID and Client Secret. It doesn’t require a Salesforce username, password, or security token in the token request. Instead, Salesforce executes API requests using the permissions of a configured Run As user. This flow works particularly well for background processes and server-to-server integrations. Step 1: Create an External Client App Salesforce recommends External Client Apps for new integrations instead of legacy Connected Apps. To create one: Navigate to Setup

In September 2025, Salesforce started blocking most users from authorizing connected apps that aren’t installed in the org. Since Spring ’26, no org can create a new connected app at all unless Support switches the permission back on, and External Client Apps are the path forward. Neither change was aimed at customer portals. Both still landed on the admins who run one. That’s the pattern with portal decisions. Whether to build or buy gets treated as a developer question (“can we build this?”) and settled at kickoff. Then the work that never stops, like permission reviews and release testing, moves to the admin team and stays there for years. So this piece skips the feature comparison. It walks through the build-versus-buy decision for a Salesforce customer portal by asking one thing: what does each option leave on the admin’s desk once the project team has gone? It’s Three Options, Not Two “Build or buy” hides a split inside “build.” Admins should name all three paths before anyone compares them. Build on the platform. You stand up an Experience Cloud site, usually on an LWR template, and write custom Lightning web components and Apex for anything Experience Builder can’t do out of the box. Every person who logs in is a Salesforce user on an external license. Build off the platform. Your developers write a separate web app that talks to Salesforce through its APIs, authenticated through a connected app or External Client App and an integration user. Portal visitors aren’t Salesforce users unless you add an identity license for them. Use a pre-built product. Someone else has already written the portal. Depending on the product, it’s either a package that runs inside Experience Cloud or an external app connected the same way as option two. Those groupings matter more than the labels. A pre-built external portal shares its architecture with a custom off-platform build. What changes is who writes and maintains the code. So before you compare vendors with developers, work out which architecture you’re signing up for. Where Does “Who Sees Which Record” Live? This is the question that sorts the options fastest, and it’s the one admins get asked about least. On the platform, it lives in your sharing model On an Experience Cloud build, Salesforce enforces visibility for every portal user. Customer Community users get access through sharing sets, since that license has no roles. Customer Community Plus and Partner Community add external roles and role-based sharing rules. Unauthenticated visitors are tighter still. Secure guest user record access has been enforced since Winter ’21 and can’t be turned off. Guest users can’t receive records through manual sharing, queues, public groups or Apex managed sharing, and the one remaining route, a guest user sharing rule, grants read-only access. That’s a strong default, and custom code can quietly undo it. An Apex controller declared without sharing, or a query that skips field-level security, will hand portal users records the sharing model would have hidden. Nothing in Setup flags it. You find it by reading code, so on-platform builds need someone who can review Apex before every release. Off the platform, it lives in someone’s code An external app reaches Salesforce through one integration user, and that user can see whatever its permission sets allow. The sharing model stops there. Deciding that customer A sees only customer A’s cases is now a filter inside the app. If your developers wrote it, the filter lives in a repository the admin team probably can’t read. If a vendor wrote it, it usually shows up as configuration. CRMJetty, for example, reads and writes through a connected app over OAuth 2.0, keeps the records in Salesforce instead of copying them, and scopes each portal user’s access by contact or account in its admin settings. Either way, the integration user still needs tight permissions. Whoever builds the portal, it should never see more than the portal is meant to show. The admin’s test: ask your developer or vendor to show you where you’d change who sees what, without a deployment. If the answer is “open a ticket,” you’ve learned who really owns your portal’s security. What Will It Cost Your Org’s Limits? Daily API requests are allocated per org over a rolling 24 hours. Enterprise Edition starts at 100,000 and adds a per-license allocation on top. The external licenses don’t add much. Customer Community licenses contribute zero calls each, while Customer Community Plus and Partner Community contribute 200 each. An off-platform portal, custom or bought, works through those APIs, so its traffic draws on the same pool as your ERP sync and every data loader job someone schedules overnight. An Experience Cloud site renders inside the platform and mostly runs into per-transaction Apex limits instead. Neither is free. They just break in different places. Two practical steps cut most of the risk: Give the portal its own integration user. Enterprise, Unlimited and Performance editions include five Salesforce Integration user licenses at no charge. They’re API-only, so a portal credential can’t be used to log in to the UI. One integration user per integration also makes the API usage report readable. Ask for the call budget in writing. Before go-live, find out how many requests a typical portal session makes and whether the app caches reference data. Then check System Overview after the first busy week and compare it with what you were promised. Who Absorbs the Release Calendar? Salesforce ships three major releases a year. Each one is a test window for anything that touches your org, and the three options carry that load differently. On-platform custom code carries the most. Every deployment to production needs at least 75% Apex test coverage with all tests passing, so a field change on the portal can turn into a test-class repair. There’s also the template question. LWR sites run only Lightning web components, and Aura components don’t work in them. A portal built on Aura custom components can’t move to the newer runtime without rewriting those

**Written by Dorian Sabitov and Antonina Kharchenko Even when data modeling, identity, and retry logic are in place, Salesforce–QuickBooks integrations often fail under real operating conditions. The most misleading Salesforce and QuickBooks sync failures are the ones that aren’t about your mappings. They’re the failures you only see under load, at the worst possible time, when finance is waiting, users are blocked, and the integration is “technically configured correctly”. What the Problem Looks Like in Practice A classic example: Salesforce sends an automated error email with “Failed 53: Bad Gateway” while QuickBooks support says there’s “no issue on their end,” leaving the team stuck and unsure whether the problem is code, licensing, or QuickBooks itself. That pattern, gateway-style failures where each system points elsewhere, is exactly what makes this category hard to debug operationally. The symptom rarely tells you whether the failure occurred: in a proxy/gateway in middleware in Salesforce outbound callout execution or upstream of QuickBooks entirely (network path, DNS, firewall, etc.) Why It Happens These errors are most often the result of “real conditions” that the initial build didn’t model: Middleware/API layer timeouts. A “Bad Gateway” is frequently a timeout or connection failure between Salesforce and QuickBooks (or between a middleware layer and QuickBooks), not a deterministic bug in business logic. Concurrent sync collisions and rate/volume spikes. Salesforce integration with QuickBooks works for a handful of records, then falls over when several transactions trigger at once (end-of-day batches, close activities, donation spikes, or backfilled jobs). No backoff strategy. When transient failures hit, naive retry behavior either amplifies the problem (retry storms) or just causes repeated failures at the same rate. Poor observability: people learn about failures from users, not monitoring. In practice, the first “monitoring” signal is an automated email and a growing backlog of transactions awaiting reconciliation. However, a common anti-pattern is: the integration has logs somewhere, but no one is alerted early enough to prevent business impact. How to Fix It To protect QuickBooks Salesforce sync against these failures, you need operational design. 1) Queue-based execution. Instead of executing callouts directly from record-triggered flows or synchronous logic, push work into a queue (platform events, queueable jobs, or middleware queues). This reduces collision pressure and gives you a control point for throughput. 2) Retry with backoff (and jitter), not immediate replays. Retries are necessary for transient errors, but they need exponential backoff and spacing to avoid retry storms. 3) Handling records that require manual correction. Some failures will never succeed without data correction (invalid tax code, missing item, invalid customer reference). These records should be moved to a clearly identified failed state with relevant error details attached, rather than being retried indefinitely. 4) Per-record logging + alerting + a sync runbook If the team only discovers failures because users complain, the integration is not operationally complete. The bare minimum is: per-record success/failure status (with correlation IDs) alerting when failure volumes increase or the success rate drops, and a short runbook with clear instructions: what to check first, where logs live, how to replay safely, and when to escalate. Why This Matters in Production Failures under real conditions are the most operationally disruptive because they occur when the business depends most on the integration. At this stage, the problem is no longer data modeling or mapping; it is system reliability. In the final post, we bring these failure patterns together and examine what they reveal about designing a Salesforce-to-QuickBooks sync that remains stable over time. Antonina Kharchenko is a Salesforce Admin with six certifications and a 2-Star Ranger on Trailhead. She works with Salesforce systems, automation, and process improvement, and enjoys turning her day-to-day experience into useful articles. Dorian Sabitov is a 4x Certified Salesforce Administrator and Developer with extensive experience in customizing Salesforce to the client’s needs. He started his journey in IT as a CRM admin and kept his focus on the Salesforce ecosystem. He loves exploring new integrations in Salesforce and spotting alternative ways to optimize business processes inside the CRM. He is currently working as a full-time Salesforce developer and contributing content to the SFApps.info educational portal.

Choosing the best Salesforce CPQ alternatives in 2026 is less about finding a one-to-one replacement for it. It is more about matching the solution to the company’s sales model, product complexity, and Salesforce architecture. The CPQ market itself reflects this variety. Gartner’s Critical Capabilities research evaluates CPQ applications across 7 use cases and 12 critical capabilities, covering scenarios from direct and channel sales to service selling, complex manufacturing, solution selling, composable CPQ, and long-term deal negotiation. This reflects how differently CPQ solutions can be designed, even when they provide the same core quoting functions. As a result, evaluating a Salesforce CPQ alternative requires more than checking whether it supports products, pricing, discounts, approvals, and quote generation. The more relevant question is how those capabilities fit the company’s sales process and Salesforce environment. Some solutions keep CPQ closely within Salesforce, while others operate as separate platforms and extend quoting into proposals, contracts, and other parts of the sales process. For this comparison, we selected 4 established CPQ solutions that integrate with Salesforce: appero quote, Conga Advantage CPQ, DealHub, and PandaDoc. They differ in product scope, implementation approach, target customers, and the broader sales capabilities they provide. Comparing them side by side can help you assess which solution fits your Salesforce environment, quoting requirements, and business needs. At a Glance Best for Salesforce-Native CPQ: appero quote. A focused CPQ application built as a native Salesforce app for product configuration, pricing, quote calculation, and document generation. Best for Complex Product Configuration: Conga Advantage CPQ. Designed for complex product catalogs and configuration requirements, with rules, dependencies, product relationships, and advanced configuration capabilities. Best for Quote-to-Revenue Workflows: DealHub. Brings quoting, approvals, contracts, subscriptions, billing, and buyer collaboration into a single revenue workflow. Best for Proposal Creation and E-Signature: PandaDoc. Combines proposal and document creation with templates, collaboration, and built-in eSignature capabilities for customer-facing sales documents. What to Consider When Choosing the Best Alternatives to Salesforce CPQ When evaluating a CPQ solution or Salesforce Revenue Cloud alternatives, it is worth looking beyond the feature list and considering how the solution fits within the Salesforce environment, how much of the sales process it covers, and what implementation and administration will require. This matters because the decision is not only about functionality. A Simon-Kucher study found that only 40% of pricing and quoting automation implementations fully succeed, highlighting clear scope, system integration, and organizational readiness as important factors. Several areas are particularly relevant when assessing a Salesforce quoting app: Salesforce integration: how the solution connects with Salesforce and how Salesforce data is used throughout the quoting process. CPQ capabilities: product configuration, pricing, discounts, approvals, quote creation, and other core quoting requirements. Implementation and administration: how the solution is set up and configured and what administrators need to manage. Security: available security features, certifications, and compliance information. Usability: how sales users work with the solution when creating and managing quotes. Additional functionality: capabilities beyond core CPQ, such as proposals, contracts, e-signature, subscriptions, or broader revenue processes. With these considerations in mind, it is useful to start by looking at each solution on its own, including its main capabilities, Salesforce integration, and approach to CPQ. appero quote: Salesforce-Native CPQ with a Focus on Quoting appero quote CPQ Light on AppExchange appero quote, developed by appero GmbH, is a Salesforce native CPQ solution focused on product configuration, price calculation, quote creation, and quote-document generation. The application natively integrates into the Salesforce opportunity process, with products, pricing, quote templates, and quote data handled within the Salesforce environment. You can consider the product as one of the PandaDoc on Salesforce CPQ alternatives, as it combines pricing logic with a visual quote editor. Users can configure products, apply pricing and discount rules, create quotes from templates or previous quotes, and generate PDF documents. It is possible to insert Salesforce data into quotes through merge fields, including information from opportunities, accounts, contacts, products, quotes, and users. Key features: appero quote supports the core functions needed for structured quoting, including: Product configuration: Product Groups, Product Properties, bundles, accessory products, and product dependencies. Pricing and discounts: graduated prices, price dependencies, surcharges, manual and automated discounts, and discount matrices. Quote creation: quote templates, reusable modules and content, and a visual Lightning Quote Editor. Salesforce data: merge fields that dynamically insert Salesforce record values into quotes. Quote documents: customizable quote layouts, formatting options, and PDF generation. Ideal use cases: Businesses that want a native Salesforce CPQ for product configuration, pricing, quoting, and document generation. Teams with standard product bundles, dependencies, and pricing requirements that do not need highly complex enterprise configuration. Salesforce CPQ customers looking for a focused CPQ replacement without moving to a broader revenue-management platform. appero quote CPQ light focuses on the core CPQ process within Salesforce, combining product configuration, pricing and discount logic, quote creation, and document generation. Its Salesforce-native architecture keeps the quoting process closely connected to Salesforce data and the opportunity process. Conga Advantage CPQ: Enterprise CPQ for Complex Product Configurations Conga Advantage CPQ on AppExchange Conga Advantage is an enterprise CPQ application from Conga, available on the Salesforce AppExchange. It is mostly for sales organizations that need to configure complex products and services, apply pricing and business rules, and generate quotes and proposals. The solution supports complex products and services, guided selling, rules-based configuration, and multiple sales channels. Key features: Conga Advantage CPQ supports: Product configuration: standalone products, bundles, options, attributes, categories, and configuration rules. Guided selling: guided product configuration based on attributes, options, and rules. Pricing and adjustments: price lists, price rules, discounts, markups, promotions, and contract pricing. Product and pricing rules: dependencies, constraints, eligibility rules, and related pricing logic. Quote creation: quotes and proposals based on configured products and pricing. Quote collaboration: multiple users can contribute to product configuration and pricing through collaboration requests on the same quote. Quote templates: reusable templates for generating quote and proposal documents with quote and pricing information. Ideal use cases: Businesses with complex product configurations that require product attributes, dependencies, compatibility rules, and configuration