Why Salesforce.com Isn’t Suited for Complex License and Entitlement Management Processes

The terms "entitlements" and "entitlement management" are also used by customer relationship management (CRM) systems, notably Salesforce.com. Understandably, software producers we serve are confused: "Do we need entitlement management from Flexera? How is it different?" A prior post addresses a related topic on why enterprise resource planning (ERP) systems are not suitable for entitlement management. Quite simply, ERP systems are intended to maintain integrity of financial transactions and are not a great fit for entitlement management. In what follows, we demystify entitlement management in Salesforce.com and demonstrate that like ERP systems, Salesforce.com will require significant customizations to solve entitlement and license management use cases, as defined by Flexera.

Salesforce.com defines entitlements as: "Entitlements help you determine if your customers are eligible for customer support so you can create cases for them. A customer may be eligible for support based on a particular asset, account, or service contract. Here's an example of how support reps use entitlements:

1. A customer calls support.

2. A support rep searches for the caller's account, contact, asset, or service contract.

3. The rep verifies there's an active entitlement on the Entitlements related list.

4. The rep creates a case from the entitlement."

Entitlements, as defined by Flexera, refers to "a record of license use rights or rights to a service, as defined through agreements between a software user (or recipient of service) and a software producer (or service provider)". Our definition is geared towards software producers, unlike Salesforce.com's definition, which is oriented for hard goods manufacturers.

Let's say Acme buys an entitlement for 1000 units of EZ-Calculator Basic under a concurrent license model with maintenance expiring on December 31, 2013. By Flexera's definition, this gives Acme the rights to use no more than 1000 instances of EZ-Calculator Basic at any given time; they can use the product forever but the software maintenance expires on December 31, 2013.

To model what was sold to Acme in Salesforce.com, you would do the following (I only show fields that are relevant to this article – actual Salesforce.com implementations have a lot more fields):

  • Create a Salesforce.com opportunity with the following line items:
    • PricebookEntryId = EZCalculatorBasic, Qty = 1000, => represents the licensed product
    • PricebookEntryId = EZCalculatorBasic Maintenance, Qty = 1 => represents the maintenance purchase 
  • Create a Salesforce.com asset with
    • AssetId = EZcalcAssetId
    • AccountId = AcmeEnterpriseId
    • Product2Id = EZCalculatorBasic
    • Quantity = 1000
    • UsageEndDate = permanent

 The asset represents the licensed product that was sold to Acme.

  • Create a Salesforce.com entitlement with
    • AccountId = AcmeEnterpriseId
    • End date = December 31, 2013
    • Type = "maintenance"
    • Service contract id = AcmeEnterpriseServiceContractId
    • AssetId = EZcalcAssetId

The entitlement tracks the maintenance rights associated with EZCalculator Basic.

You have to do all this manually but once this is set up, when Acme calls the producer, the producer's rep would be able to see that (a) Acme has a valid (or expired) maintenance plan and (b) Acme originally purchased 1000 units of EZ Calculator Basic. But that's about it. Out of the box, this is all you get with Salesforce.com.

The reality is, to run a software business you have to build a lot of custom workflows around the Salesforce.com entitlement and asset objects. In fact, a publisher I spoke with has built a custom maintenance renewal process by extending the product, asset and entitlement objects through Force.com custom fields and added a lot of custom code to process each opportunity in the "closed-won" state to:

  • Create an asset automatically if product type = "licensed product" (Note: product type is a custom field on the Force.com product object)
  • Create an entitlement of type "maintenance" automatically if product type = "maintenance"
  • Create a renewal opportunity with a forecast close date one year in the future if product type = "maintenance"

They estimated that building just this one process in Salesforce.com took about 8 person-months of effort for the initial development plus additional effort to fine tune it as business needs changed. In addition, the IT team of this publisher had to become experts in renewal processes before they could even build such a custom application.

Next time—Why Publishers Need a Proven Commercial License and Entitlement Management System to Support the Full Software Lifecycle Process


Leave a Reply

Your email address will not be published. Required fields are marked *