My firm is undergoing an architectural overhaul of the way our SFDC instance is organized, as part of a move from selling perpetual software licenses to selling subscriptions.
I've been trying to research how Salesforce themselves handle subscriptions, based on the extensive talk given by their Renewals team at Dreamforce 2013
1 hour talk on their architecture: http://www.youtube.com/watch?v=NV9024qkZMQ
My question is around the long-term storage of their customers' subscriptions. We want to mimic the sOject design that they have, with similar behavior. We want to have the next year's opp auto-create after the current year's opp closes. We want to have a single contract underneath the renewal opp with the terms and expiry date.
This is all in line with Salesforce's architecture.
My questions is this:
Does anybody have any idea about either best practices or how Salesforce is handling their customers' set of products (subscriptions).
Are they handled entirely by the opp in the line items, or is the opp filled by some table/object with a list of subscribed products per account?
My understanding is that Salesforce has set up the opp itself to master this data, and the next year's opp is populated by cloning of the current year's opp. This is the only line item view of products owned by the associated account.
Does this seem right? Can anybody verify that they've seen it done this way? Can anybody speculate on the nature of the 'Renewal' object in the slide above. Could that be a capture of the transaction (payment event), or is it more likely product line items.
Thanks for any insight on this. Obviously its a big decision, and we haven't gotten a definitive answer yet from Salesforce themselves, though we're trying.