Automatic Subscription Build
Automatic subscription building helps managing subscriptions if your business requires to deal with a large or variable – read: increasing – number of subscriptions.
The way to set up the subscription builder depends on the nature of your products, your sales use cases and the representation of your source data in Salesforce.
(1) Billing an account-specific set of products under some account-specific conditions → parent-child relationship
(2) Billing identical products on equal conditions to multiple accounts → master subscription
(3) Creating or updating subscriptions based on additional data or custom objects → data mapping
Related information:
Automatically Building Subscriptions
Subscription Builder Setup Options
Setup Approaches
Parent-Child Relationship
Used to bill an account-specific set of products under some account-specific conditions
To allow for individually configured items when building subscriptions, you can use objects that are in a parent-child relationship, like orders with order products. If set up accordingly, the subscription builder takes the parent object ( order) to produce the subscription, and the child objects ( order products) to produce the subscription items.
In order to create price tiers for items, JustOn also supports subchild relations. You can configure custom objects to hold the price tier information and relate them to the child objects via lookup or master-detail relations. The subscription builder then takes the subchild records to produce the price tiers for the subscription items.
Building subscriptions based on accordingly configured objects
Note
When creating price tiers from subchild records, be aware of the following limitations:
- Some Salesforce objects are not allowed to be the target of a lookup relation, including, for example, Order Product. When using one of these objects to create subscription items, it is not possible to configure a subchild object for creating price tiers.
- When updating subscriptions automatically, any created price tiers are not included.
Master Subscriptions
Used to bill identical products on equal conditions to multiple accounts
A master subscriptions is a subscription "model" that is copied for each target. The target is the object whose records are the basis for subscriptions, like accounts, contracts, cases, quotes, etc. If set up accordingly, the subscription builder can generate an individual subscription for each new account, contract, case, quote, etc. that you create.
Building subscriptions based on a master subscription
Data Mapping
Used to create or update subscriptions based on additional data or custom objects
Data mappings allow for retrieving the data required for creating or updating subscriptions and their items from virtually any fields of any objects. Generally, you can apply mappings to get data
- in addition to the configured fields when using master subscriptions or objects in a master-detail relationship, or
- from customized source objects whose records hold all (variable) information for creating subscriptions and items.
Building subscriptions based on a mapping
Handling New Source Data
Your business activity may change the subscription builder source data. The type of change determines the subscription builder operation:
The source record that has originally triggered the subscription builder, producing a subscription, may be modified. To cover this case, you can configure the subscription builder to update existing subscriptions after a value of a source record field has changed, or – in a parent-child relation – a new child record is added. Once set up, this copies the new source data and adds new items, if applicable.
See Subscription Update.
The source record that has originally produced the subscription may be complemented or replaced by a new source record of the same type. In this case, the subscription builder logic applies – either automatically or as configured – one of the defined use cases NEW, REORDER or UPGRADE.
Info
The way to add new subscription items to an existing subscription depends on whether you
- add a new child source record to an existing parent source record → subscription update incl. option to create new items
- add a new child source record using a new parent source record → subscription builder use case
REORDER
Subscription Update
Certain business cases require automatically updating existing subscription fields or subscription item fields after the subscription has been built (applying one of the subscription builder use cases). This may be necessary, for example, after the value of a source object field has changed.
The automatic subscription update makes use of the subscription builder and depends on the checkbox ON_UpdateSubscription on the source object. It controls whether the already generated subscription – linked by ON_Subscription on the source record – is to be updated. In addition, you define the fields to be updated and control whether to create new items (from new child records).
Once set up, selecting the checkbox ON_UpdateSubscription triggers the automatic subscription update. The subscription builder "simulates" the use case NEW and copies the fields selected to be updated. After completing the update, the subscription builder deselects the checkbox ON_UpdateSubscription and sets a date in ON_LastSubscriptionUpdate.
Enabling Subscription and Subscription Items Update
Subscription Builder Use Cases
The subscription builder supports three different use cases for the subscription building. They map typical sales use cases:
| Use Case | Description |
|---|---|
| NEW | Creates a new subscription. |
| REORDER | Creates new items and adds them to an existing subscription. If there is no existing subscription, it builds a new subscription. Adding a new child source record to an existing parent source record is covered with the subscription update including the option to create new items. |
| UPGRADE | Creates a new subscription, sets an end date on the existing subscription and sets its status to Upgraded. Certain items (active, not already available, not excluded, matching service period) of the existing subscription are cloned and added to the new subscription. |
The use cases can be set in the field ON_UseCase on the subscription source record. If the field is missing or not set, JustOn determines the use case automatically.
Use cases example
To illustrate the use cases, assume the following example: You sell phone contracts, and you keep track of your deals using opportunities. For each opportunity you generate a subscription, which is finally invoiced.
When you close a deal with a new customer, the new (or updated) opportunity triggers the creation of a new subscription. This is covered with the use case NEW.
Now an existing customer orders an additional service, which you add as a new opportunity product on a new opportunity. This opportunity product becomes a new subscription item on the existing subscription. This is the use case REORDER – you add new subscription items, leaving the existing in place.
If, however, the customer decides to upgrade the calling plan, you usually refund the amount that is already paid for the rest of the current contract term. This is where you apply the use case UPGRADE: you create a new subscription that includes items for new products as well as credit items for products to be refunded, and the existing subscription terminates.