MuleSoft is the integration platform that Salesforce acquired in 2018 and has positioned as the connectivity layer between Salesforce and the broader enterprise application landscape. It is one of the most strategically important and commercially complex products in the Salesforce portfolio, sold under a licensing model that has evolved significantly since the acquisition and that continues to evolve as Salesforce repositions MuleSoft within the Einstein 1 and Hyperforce architecture. This guide is the comprehensive enterprise reference for MuleSoft licensing, pricing, and negotiation.
It is written for IT architecture leaders, integration platform owners, procurement leaders responsible for middleware spend, and the technical operations teams that build and run on MuleSoft Anypoint Platform. It covers the Anypoint Platform pricing structure, the message-based versus capacity-based pricing models, the API Manager and Runtime pricing, the IDP and integration AI add-ons, and the specific negotiation tactics that move MuleSoft contracts.
The MuleSoft product structure
MuleSoft Anypoint Platform is the umbrella name for a portfolio of integration capabilities sold under various commercial structures. The core product is the Mule runtime engine that executes integration flows, packaged with API management, design tooling, and runtime management capabilities.
| Component | Function | Pricing Anchor |
|---|---|---|
| Anypoint Studio | Integration flow design IDE | Per developer / included |
| Mule Runtime | Integration execution engine | Per vCore or per message |
| API Manager | API design, security, throttling | Per API / per call |
| Anypoint Exchange | Connector marketplace | Bundled / per connector |
| Anypoint Monitoring | Runtime observability | Per environment / included |
| API Community Manager | Developer portal | Add-on |
| RPA (Robotic Process Automation) | Bot-based process automation | Per bot |
| Intelligent Document Processing | AI document extraction | Per document / consumption |
The commercial complexity comes from how these components are bundled and how the underlying consumption is metered. The two primary commercial models — capacity-based (vCore licensing) and consumption-based (message-based licensing) — have substantially different economics and are appropriate for different operational profiles.
The vCore capacity model
The original MuleSoft pricing model is the vCore capacity model. A vCore is a unit of compute capacity provisioned for the Mule Runtime, and the enterprise commits to a defined number of vCores at a defined annual rate. The vCore count is a procurement-level decision that maps to the integration workload and to the desired performance envelope.
The negotiation around vCore pricing focuses on the per-vCore annual rate, the volume discount structure (which produces materially lower per-vCore rates at higher vCore commitments), the deployment flexibility (CloudHub-managed versus customer-deployed), the production versus non-production vCore mix, and the high-availability structure (which can double or quadruple effective vCore counts for production workloads).
| vCore Commitment | Achieved Per-vCore Annual Range | Notes |
|---|---|---|
| 10 – 50 vCores | $18,000 – $28,000 | Midmarket; limited volume leverage |
| 50 – 200 vCores | $13,000 – $22,000 | Enterprise; meaningful volume discount |
| 200 – 1,000 vCores | $9,000 – $16,000 | Large enterprise; substantial leverage |
| 1,000+ vCores | $6,000 – $12,000 | Strategic; bespoke deal structures |
These ranges represent achieved per-vCore pricing across enterprise customers running structured negotiations. The list per-vCore rate is typically $30,000 to $40,000, so the achieved enterprise pricing represents 50% to 75% discount from list at the higher commitment tiers.
The message-based consumption model
Salesforce has progressively shifted MuleSoft pricing toward a message-based consumption model in which the enterprise commits to a defined number of messages processed per year. A message is defined as a single integration event flowing through the Mule Runtime, with definitions that have evolved over time and that require careful attention in the contract.
The message-based model aligns commercial cost with operational use in principle, but it introduces complexity that the vCore model does not have. Message definition matters enormously: an integration flow that processes a single inbound request and produces three outbound API calls may be counted as one message or four messages depending on the definition. Bulk operations, real-time streaming, and event-driven architectures each have different message accounting implications.
The buyer-side approach to message-based pricing is to negotiate the message definition explicitly in the contract, to model projected message volume with rigor before committing to a tier, to negotiate the per-message rate aggressively at the projected volume tier, and to negotiate the true-up structure for overage above the committed volume.
| Message Volume Tier | Annual Messages | Achieved Per-Million-Message Rate |
|---|---|---|
| Entry | 10M – 100M / year | $1,200 – $2,500 |
| Midmarket | 100M – 1B / year | $800 – $1,500 |
| Enterprise | 1B – 10B / year | $400 – $1,000 |
| Strategic | 10B+ / year | $200 – $600 |
Our MuleSoft message commitment was sized to peak-day extrapolation. Actual annual volume was 60% of the commitment. We restructured to a vCore-based contract at renewal because our integration architecture had high message variability that made capacity-based pricing more cost-effective.
— Director Integration Platform · InsuranceThe vCore versus message decision
For most enterprises, the choice between vCore and message-based pricing is the most important MuleSoft architectural decision. The economics differ substantially based on the integration profile.
vCore pricing tends to favor enterprises with steady, high-throughput integration workloads where the compute capacity is consistently utilized. The fixed per-vCore cost spreads across all the messages processed, producing favorable per-message economics for high-utilization workloads.
Message-based pricing tends to favor enterprises with variable workload patterns where vCore capacity would be under-utilized during low-volume periods. The pay-per-message model means the enterprise only pays for actual integration activity, with no fixed capacity cost during low-volume windows.
The break-even analysis depends on the projected message volume, the workload variability profile, and the per-vCore versus per-message pricing achievable. Most enterprises will benefit from running the analysis explicitly rather than accepting the pricing model the account team recommends. Salesforce's recommendation often follows internal sales motion preferences rather than buyer-side economic optimization.
API Manager and API-led architectures
API Manager is the MuleSoft component that handles API design, security policy enforcement, throttling, analytics, and developer portal management. It is essential for enterprises adopting API-led integration architectures and is priced either bundled with the Runtime or as a separate add-on depending on the deployment model.
The negotiation around API Manager focuses on the per-API pricing (which can scale rapidly for enterprises with large API catalogs), the per-API-call pricing (which can dominate cost for high-traffic APIs), and the developer experience features (Community Manager, developer portal, sandbox environments). The most common buyer error in API Manager is paying for capabilities that are not actually being used in the API-led architecture.
The Salesforce Composer relationship
Salesforce Composer is a lighter-weight integration capability sold under the Salesforce platform umbrella, separate from full MuleSoft Anypoint Platform. It is designed for citizen-integrator use cases — connecting Salesforce to common SaaS applications without the technical complexity of full MuleSoft deployment.
The negotiation question for many enterprises is whether the integration footprint requires full Anypoint Platform or whether Composer can serve the use cases at lower cost. The answer depends on the integration patterns: simple SaaS-to-SaaS connections may be well served by Composer, while complex enterprise integration patterns (legacy system connectivity, high-volume message processing, mission-critical reliability) typically require Anypoint Platform.
The commercial implication is that some enterprises pay for full Anypoint Platform when Composer would meet their use cases at lower cost, while others use Composer when the operational requirements exceed Composer's capabilities. The remedy is the integration architecture assessment that maps each integration use case to the appropriate MuleSoft commercial structure.
The Intelligent Document Processing and AI overlay
MuleSoft Intelligent Document Processing (IDP) is the AI-powered document extraction capability that converts unstructured documents (invoices, contracts, forms) into structured data for integration into downstream systems. It is priced per document processed, with per-document rates varying by document complexity tier.
IDP and the broader AI integration overlay in MuleSoft are areas where Salesforce is actively expanding the product portfolio and the commercial structure. Enterprises evaluating these capabilities should model the projected consumption carefully, negotiate the per-document or per-AI-operation rates aggressively, and negotiate graduated commitment structures that allow scaling based on demonstrated value rather than aspirational deployment.
Deployment flexibility: CloudHub, RTF, and customer-deployed
MuleSoft offers multiple deployment models with different commercial implications. CloudHub is the fully managed Anypoint Platform deployment on Salesforce-managed infrastructure. Runtime Fabric (RTF) is the customer-deployed runtime container that runs on customer-controlled Kubernetes infrastructure. Customer-deployed standalone Mule deployments run on customer infrastructure without the broader Anypoint management layer.
The commercial implications vary. CloudHub pricing typically includes the infrastructure and management overhead in the per-vCore or per-message rate. RTF pricing separates the licensing from the infrastructure, allowing the enterprise to control infrastructure cost while paying for the MuleSoft software. Customer-deployed standalone is the lowest-cost commercial structure but requires the enterprise to manage the runtime infrastructure entirely.
The negotiation around deployment model is to evaluate which model fits the enterprise's operational profile, to negotiate the appropriate pricing for that model, and to preserve the right to migrate between models during the contract term as operational requirements evolve.
The MuleSoft benchmark
MuleSoft benchmarks are best expressed in two units: annual cost per vCore (for capacity-based contracts) and annual cost per million messages (for consumption-based contracts). Both should be calculated on actual deployed capacity or actual delivered messages rather than on committed capacity, because the relationship between commitment and actual use varies substantially.
| Segment | Contract Type | Effective Cost Range |
|---|---|---|
| Midmarket vCore | 50 – 200 vCores | $13,000 – $22,000 per vCore |
| Enterprise vCore | 200 – 1,000 vCores | $9,000 – $16,000 per vCore |
| Midmarket Messages | 100M – 1B / year | $800 – $1,500 per million |
| Enterprise Messages | 1B – 10B / year | $400 – $1,000 per million |
The competitive integration landscape
MuleSoft competes with a broad set of integration alternatives that create real negotiation leverage when documented credibly. Workato is a credible alternative for citizen-integrator and SaaS-to-SaaS use cases. Boomi competes across the full enterprise integration platform space. Informatica Intelligent Data Platform is competitive for data integration use cases. SnapLogic is competitive for cloud-native integration. Open-source alternatives like Apache Camel running on customer-managed Kubernetes provide a build-versus-buy comparison for enterprises with strong internal integration engineering capability.
The competitive evaluation that produces real leverage is the evaluation Salesforce understands you have conducted. MuleSoft is a segment with multiple credible alternatives, and Salesforce knows this. Documented evaluation, scoring methodology, named alternatives, and an executive sponsor whose name appears on the evaluation memo are the markers of credibility that translate to negotiation leverage.
The MuleSoft bill of rights for the buyer
The following contractual rights are the structural protections we expect every enterprise MuleSoft contract to include.
The right to commercial model flexibility: the contract should permit migration between vCore and message-based pricing models during the term, recognizing that operational profile evolves and the right commercial model can change over multi-year horizons.
The right to message definition transparency: for message-based contracts, the message definition should be specified in the contract with sufficient precision to allow the enterprise to model and verify message accounting.
The right to deployment model flexibility: the contract should permit migration between CloudHub, RTF, and customer-deployed standalone during the term, with pricing adjusted accordingly.
The right to expansion at contracted rates: incremental vCores or messages added during the term should be priced at the original contracted rate, not at then-current list.
The right to true-up at contract rate: overage above committed capacity or message volume should be billed at the contracted rate or a modest defined premium, not at list.
The right to reduction at renewal: if actual consumption falls below commitment, the renewal commitment should be permitted to reduce to actual levels without penalty.
The right to API and connector inclusion: the contract should specify which connectors and API features are included versus separately priced, and should include the right to access new connectors released during the term at no additional cost.
What success looks like for MuleSoft
A well-negotiated enterprise MuleSoft contract delivers the following outcomes. Per-vCore or per-message pricing at or below the midpoint of the benchmark range for your segment. Commercial model (vCore versus message) matched to the enterprise's integration profile through deliberate analysis rather than account team recommendation. Commitment sized to projected actual consumption with defined buffer, not aspirational over-commitment. Deployment model (CloudHub, RTF, customer-deployed) optimized for operational requirements and cost. True-up rates at contract pricing rather than list. Reduction rights at renewal. Connector portfolio aligned with actual integration footprint. Co-termed end date with broader Salesforce portfolio.
The enterprises that consistently achieve these outcomes share a few practices. They model integration workload carefully before selecting a commercial model. They evaluate vCore versus message economics explicitly. They preserve commercial model flexibility in the contract. They benchmark per-vCore and per-message pricing against achievable enterprise rates. They evaluate competitive alternatives credibly. And they treat MuleSoft as a strategic platform investment that deserves strategic negotiation.
Common MuleSoft pitfalls
The recurring patterns we observe in MuleSoft negotiations are predictable and avoidable.
Pitfall one: peak-day sizing
The most common MuleSoft pitfall is sizing the commitment to peak-day extrapolation rather than projected actual consumption. Peak-day extrapolation produces commitments that are 30% to 60% higher than actual annual consumption, with the over-commitment representing pure overspending under the consumption model and pure idle capacity under the capacity model.
Pitfall two: accepting the recommended commercial model
Salesforce account teams have internal preferences for vCore versus message-based contracts that may not align with the buyer's economic optimum. The pitfall is accepting the recommended model without running the break-even analysis. The remedy is the explicit analysis that compares the two models under the enterprise's actual integration profile.
Pitfall three: ignoring message definition
For message-based contracts, the message definition determines the actual cost. The pitfall is accepting the default definition without examining how it applies to the enterprise's integration patterns. The remedy is the contract-level negotiation of the message definition with sufficient precision to allow modeling and verification.
Pitfall four: paying for unused connectors
The Anypoint Exchange connector portfolio is broad, and many enterprises pay for connectors that are not actively used. The pitfall is the bundled connector pricing that obscures which connectors are deriving value. The remedy is line-item connector accounting and the right to remove unused connectors at renewal.
Pitfall five: no deployment model flexibility
The deployment model (CloudHub, RTF, customer-deployed) appropriate for an enterprise can change over a multi-year contract horizon as cloud strategy evolves and as Kubernetes infrastructure matures. The pitfall is locking into a single deployment model without flexibility provisions. The remedy is the contractual right to migrate between deployment models during the term.
The MuleSoft strategic position
MuleSoft sits at the intersection of enterprise architecture and Salesforce platform strategy. For enterprises with significant Salesforce footprint and substantial integration requirements, MuleSoft can be a strategic platform that consolidates integration capability under a unified commercial relationship. For enterprises with simpler integration requirements or with strong existing integration platform investment, MuleSoft may be a tactical capability for Salesforce-specific connectivity rather than a strategic enterprise integration platform.
The negotiation strategy follows the strategic positioning. Strategic-platform enterprises accept tighter commercial coupling in exchange for the consolidation value. Tactical-capability enterprises negotiate for flexibility and lower commitment in exchange for narrower scope. The error is failing to clarify the positioning and negotiating ambiguously.
The closing word on MuleSoft
MuleSoft is the most architecturally consequential product in the Salesforce portfolio. The integration platform decision shapes how the enterprise connects its application landscape, how it deploys new capabilities, and how it manages data flow between systems. The commercial structure of the MuleSoft contract supports or constrains those architectural decisions for years after signature.
The enterprises that approach MuleSoft negotiation strategically — with clear integration architecture, with documented vCore-versus-message analysis, with credible competitive alternatives, with deployment model flexibility — produce contract outcomes that support strategic integration capability at favorable economics. The enterprises that approach MuleSoft as a routine middleware procurement produce contracts that constrain integration flexibility and that absorb avoidable overspending across the multi-year term.
The work to negotiate MuleSoft well includes integration workload modeling, commercial model analysis, deployment model evaluation, connector portfolio audit, competitive alternative documentation, and contractual flexibility provisions. The work is detailed but the returns are substantial: well-negotiated enterprise MuleSoft contracts capture 30% to 45% reductions against initial proposal and preserve architectural flexibility that supports strategic integration capability for the contract life.
If you have a MuleSoft renewal or new commitment on the horizon, the time to start the negotiation work is now, with the integration architecture team and the procurement function working together to build the analytical foundation for a strategic negotiation. The connection layer your enterprise applications use to talk to each other is the foundation on which the application portfolio operates. Build the foundation right.
One additional principle: integration as a strategic capability
Integration is increasingly recognized as a strategic capability rather than a tactical concern. Enterprises that can connect systems quickly, securely, and reliably gain meaningful competitive advantage. Enterprises that struggle with integration find that every new initiative — new product launch, new market entry, new acquisition integration — is bottlenecked by the connectivity layer.
The MuleSoft commercial structure should support strategic integration capability. That means commitment levels that match strategic ambition without producing crippling overspending, deployment flexibility that supports cloud strategy evolution, message and connector economics that reward expansion of integration capability rather than penalizing it, and contractual protections that preserve flexibility across the multi-year horizon of strategic transformation.
The contract is the foundation. The integration platform is the operational reality. The strategic capability is what the enterprise builds on top of both. Each layer depends on the layer below it. Negotiate the contract with the strategic capability in mind, and the integration platform will support what the enterprise needs to build. Negotiate the contract as a routine procurement, and the integration platform will become a constraint rather than an enabler.
The choice between these postures is the choice the enterprise makes at the next contract cycle. Make it deliberately.
Deep dive: the vCore sizing methodology
vCore sizing is the analytical foundation of any capacity-based MuleSoft contract. The methodology that produces defensible vCore counts begins with an inventory of integration workloads — the specific flows, APIs, and integration patterns running on the platform — followed by an analysis of the compute requirements of each workload under realistic traffic profiles.
The default account team approach to vCore sizing tends to add buffer at every layer: buffer for high availability, buffer for growth, buffer for peak load, buffer for development environments. Each buffer layer is defensible in isolation. Stacked together, the buffers can double or triple the actual production vCore requirement. The buyer-side counter is to size each buffer layer explicitly, to challenge each layer with documented evidence, and to commit to a vCore count that reflects realistic operational requirements rather than worst-case-stacked extrapolation.
The sizing exercise also surfaces opportunities to optimize integration workloads to reduce vCore consumption. Inefficient flow design, over-provisioned worker counts, and unnecessary high-availability redundancy all consume vCore capacity without proportional value. Optimizing these patterns during the sizing exercise can reduce the required vCore commitment by 20% to 40% without reducing operational capability.
Deep dive: the message accounting question
For message-based MuleSoft contracts, the message accounting methodology is the most consequential variable in the actual cost picture. The default Salesforce message definition counts each integration event as a message, with no differentiation by event type or complexity. Under this definition, a flow that handles a simple inbound webhook and produces an outbound API call may count as one message or two messages depending on the implementation pattern.
The buyer-side approach is to negotiate the message definition explicitly, with examples documented in the contract that establish how specific integration patterns map to message counts. Examples should cover the patterns the enterprise actually uses — sync request/response, async event streaming, bulk file processing, batch jobs, event-driven workflows — so that the contract definition can be applied unambiguously to actual operations.
Without explicit definition, message accounting disputes are a recurring source of friction in MuleSoft contracts. The disputes are resolved in Salesforce's favor under the default contract terms because the platform is the source of truth for message counting and the buyer has limited audit visibility. With explicit definition and contractual audit rights, the disputes can be resolved on the evidence and the buyer can verify that the actual message counts align with the contract definition.
Deep dive: the connector and integration asset portfolio
The Anypoint Exchange connector portfolio includes connectors for hundreds of enterprise applications, databases, protocols, and SaaS services. Many enterprises pay for the full connector portfolio when they actually use only a fraction. The connector pricing structure has evolved over time, with some connectors bundled into the platform license and others priced as separately licensed assets.
The buyer-side approach to connector negotiation is to audit which connectors are actually deployed in production integration flows, to identify which are licensed but not in active use, and to negotiate the portfolio down to what is actually being used. The audit also surfaces opportunities to consolidate similar integration patterns to a smaller set of connectors, reducing the overall connector footprint.
For new connectors introduced during the contract term, the buyer should negotiate inclusion rights so that new connectors released by MuleSoft are available without separate licensing. This protects against the situation where the enterprise needs a newly released connector mid-term and faces commercial friction over its inclusion in the existing contract.
Deep dive: high availability, disaster recovery, and the production environment question
Mule Runtime deployments for production workloads typically require high availability (multiple worker instances for redundancy) and disaster recovery (geographic distribution of runtime capacity). Each requirement multiplies the vCore count for the workload: a single-worker development deployment may need 1 vCore; the same workload in production HA may need 4 vCores; the same workload in production HA with DR may need 8 vCores or more.
The multiplication is operationally necessary for mission-critical integration workloads. It is also a substantial cost driver that deserves careful evaluation. Not every workload needs full HA and DR. Distinguishing between mission-critical workloads that require full redundancy and less-critical workloads that can operate with lighter redundancy is essential to right-sizing the vCore commitment.
The buyer-side approach is to classify workloads by criticality, to assign redundancy levels appropriate to each criticality class, and to size the vCore commitment to the aggregate of right-sized workload deployments. This exercise typically reduces vCore commitment by 15% to 30% relative to the default approach of treating all workloads as if they require full HA and DR.
Deep dive: API governance and the developer experience
For enterprises adopting API-led integration architectures, the API governance and developer experience layer of MuleSoft becomes commercially significant. API Manager provides API design, security policy enforcement, throttling, and analytics. Community Manager provides the developer portal experience for internal and external API consumers. Together they support the API governance discipline that mature API programs require.
The pricing for these capabilities can be substantial. API Manager pricing scales with the API portfolio size and the API call volume. Community Manager is typically a separate add-on with its own pricing structure. Enterprises with large API programs can find that the governance layer costs as much as or more than the underlying runtime.
The negotiation around API governance focuses on the per-API pricing tier appropriate to the actual API portfolio, the per-call pricing for high-traffic APIs, the developer portal feature scope appropriate to the developer community, and the integration between API governance and the broader Anypoint Platform. The most common buyer error is paying for governance capabilities that are not actively used in the API program.
Deep dive: the Salesforce-MuleSoft commercial integration
MuleSoft is increasingly bundled with broader Salesforce contracts, with bundle discount structures that can be advantageous for buyers purchasing across multiple Salesforce clouds plus MuleSoft. The bundle structure also creates risks: the MuleSoft pricing can become obscured within blended bundle pricing, making it difficult to evaluate whether the MuleSoft component is competitively priced.
The buyer-side approach is to negotiate MuleSoft pricing on its own merits, with line-item visibility, even when the contract is structured as a multi-product bundle. The bundle discount should be applied as a transparent adjustment to the line-item pricing rather than as a blended rate that hides the per-product economics.
This discipline is particularly important for MuleSoft because the credible competitive alternatives (Workato, Boomi, Informatica, SnapLogic, custom build) are real and substitutable in a way that some Salesforce clouds are not. The competitive context creates negotiation leverage that disappears if the MuleSoft pricing is obscured in bundled rates.
Deep dive: the multi-region and data residency considerations
For enterprises operating across multiple regions, MuleSoft deployment has data residency and regional capacity implications. Anypoint Platform offers regional deployment options that keep integration processing within specific geographic boundaries for data residency compliance. CloudHub deployment regions, RTF deployment topology, and the data flows that cross regional boundaries all affect both technical architecture and commercial structure.
The negotiation around multi-region MuleSoft focuses on the per-region pricing structure, the data flow accounting between regions, the regional deployment flexibility, and the compliance assurance for specific data residency requirements. Enterprises with complex regional operations should negotiate a global contract that consolidates regional deployments under unified commercial leverage while preserving the operational flexibility to deploy capacity where it is needed.
Deep dive: the migration consideration
Migration to or from MuleSoft is a substantial undertaking that affects both the negotiation leverage and the contractual protections that should be in place. Migrating to MuleSoft from an existing integration platform involves implementation cost, parallel operation, and risk during transition. Migrating away from MuleSoft involves similar costs and risks in the reverse direction.
The negotiation implication is that contractual transition protections matter even more for MuleSoft than for some other Salesforce products because the platform is operationally critical and the migration path is technically complex. The contract should include transition assistance provisions, data and configuration export rights, and reasonable timelines for any future migration that the enterprise might undertake.
These protections cost nothing if never invoked. They are essential if the enterprise ever needs to migrate. The asymmetry favors negotiating them in advance, before any specific migration scenario is on the table, when the negotiation context is favorable rather than adversarial.
Final principle: integration is forever
The final principle for MuleSoft negotiation is that integration platforms persist across multiple cycles of application portfolio change. The Salesforce footprint will evolve. The application landscape will evolve. The cloud strategy will evolve. Through all of these changes, the integration platform remains as the connecting layer that makes the evolving portfolio work together. MuleSoft commitments made today will be running in some form ten years from now, even as everything around them changes.
This durability makes the contract negotiation more consequential than it might appear. The structural decisions — vCore versus message, deployment model, connector portfolio, governance layer, regional architecture — shape the operating model of the integration platform for years. Negotiate accordingly.
The MuleSoft negotiation cycle is one of the few in the Salesforce portfolio where the credible competitive alternatives are genuinely substitutable, where the consumption-versus-capacity choice meaningfully changes the economics, and where deployment topology decisions carry both technical and commercial implications that span the contract life. Enterprises that treat the negotiation with the rigor it deserves capture material savings and preserve strategic flexibility. Enterprises that treat it as routine middleware procurement accept structures that constrain integration capability and drive avoidable overspending for years. The work is detailed. The payoff is structural and durable.