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 software from Revenera? 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 software 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 Revenera.

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 Revenera, 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 Revenera’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.

Revenera FlexNet Operations enables you to monetize software effectively and manage compliance and customer growth. It manages the dynamic nature of software entitlements to support all monetization models—from more traditional perpetual models to flexible subscription and pay-per-use models.

One comment on “Why Salesforce.com Isn’t Suited for Complex License and Entitlement Management Processes

  1. j166429 on

    Interesting article, but I’m very surprised at the amount of time required to implement the custom process for what is essentially just the automatic creation three records (asset, entitlement and opportunity) . Even if this article was published in 2013 it should have been relatively straightforward to implement. I’d been interested to know more on the specifics of the use case , which would surely provide more explanation as to the difficulties encountered.


Leave a Reply

Your email address will not be published.