Status Life Cycle Definitions

Status Policies

Status policies are pre-defined business rules (such as purchase an offer or add a member to a group) that determine which actions are possible when an object has a specific status. All status policies are allowed by default. For more information, see the discussion about status policies.

Status Transitions

Status transitions include conditions and actions.

• Transition Conditions
  An object transitions to a new status based on a set of conditions. If any of the conditions are true, the transition to the new status occurs. The following rules apply to transitions.

  • There can be only one transition from Status 1 to Status 2.
  • A transition from Status 1 to Status 2 causes the same actions to occur regardless of why the transition occurred.
  There are four condition types that can trigger an auto-transition:

  • Activity
    Activity transition conditions include the following:

    • First Activity
    • Balance Topup
    • Balance Transfer From
    • Balance Adjust
    • Balance Payment
    • Balance Recharge

    The first condition to occur triggers the transition.

    Note: During purchase validation, the system verifies the balance template ID is set and is not 0.
    Consider the following example.

    • A transition has two conditions:

      • MtxStatusConditionBalanceAdjust (balance template ID: 1)
      • MtxStatusConditionBalanceTopup (balance template ID: 2)

      Either of these conditions will trigger the transition.

  • Inactivity

    The first inactivity transition condition to occur as defined by an activity type or a purchase offer ID triggers the transition. The inactivity period is compared to the difference between the LastActivityTime and the current time. If the difference is greater that the inactivity period, the state transition occurs.

  • Balance expiration
    If multiple MtxStatusConditionBalanceExpiration conditions are specified (with different delay periods), the following algorithm is used:

    1. The Charging Server evaluates all the MtxStatusConditionBalanceExpiration conditions defined within one single status transition. The MtxStatusConditionBalanceExpiration condition that has latest (maximum) EndTime is used as the calculated transition time per status transition object.
    2. The calculated transition time (as determined by Step 1) for each status transition object defined for an object status are compared. The earliest (minimum) transition time is used for the object.

    Note: This algorithm is stateless with respect to previous state transitions. Therefore, if an object transitions from Status A to Status B due to balance expiration condition, transitioning back to Status A will result in a transition back to Status B unless the EndTimes of the balance instances in the balance expiration condition are updated such that they are no longer expired.

    For example:

    1. Status A has two transitions, one to Status B and another to Status C.

       • The transition to Status B has two balance expiration conditions: when Balance 1 expires and when Balance 2 expires.
       • The transition to Status C has one balance expiration condition: when Balance 3 expires.

       No transition takes place until all the balances within a single transition have expired.

    2. The balances expire as follows:
       • Balance 1: 2021-01-01
       • Balance 2: 2021-02-01
       • Balance 3: 2021-03-01
    3. All the balance expiration conditions are compared within each status transition object. For the transition to Status B, which has two balance expiration conditions, the latest (maximum) EndTime is 2021-02-01.
    4. For each status transition object defined for an object status, the calculated transition times are compared.
       • The calculated transition time for transitioning to Status B is 2021-02-01.
       • The calculated transition time for transitioning to Status C is 2021-03-01.
       Therefore, the object transition to Status B because it has the earliest (minimum) transition time.
  • Recurring Processing Failure

    Recurring processing can fail when a subscription or group has insufficient funds or credit to pay recurring charges.

  For more information about transition conditions, see the discussion about status conditions.

• Transition Actions

  Actions can be applied to an object with a specific status. By default, all actions are permitted.

  If a status transition includes transition actions, the actions must succeed in order for the transition to succeed. If a provisioning operation (such as a top-up, offer purchase, and so forth) causes a state change and a transition action fails, the provisioning request fails.

  If an automatic transition occurs on a provisioning request (such as a top-up, offer purchase, and so forth), the state transition occurs before rating occurs for the purchase.

  The following actions can occur during transitions between device, subscription, and group object statuses only. They do not apply to user object statuses.

  • Activate all offers
  • Cancel a specific offer ID if owned
  • Cancel all offers
  • Modify parent status
    Note: If a subscription is a member of multiple groups, the modify parent status action is executed for each immediate parent group. Because this action has an expected status, it only changes the parents meeting this condition. If the group changes status and that status change also has a modify parent status action, then the "grandparent" is changed, too. If changes are needed further up the hierarchy then each parent group needs to modify parent status (and the grandparent groups, and so forth).
  • Suspend all offers
    Note: When a bundle is suspended, all offers within the bundle that can be suspended are suspended. For more information about bundles, see MATRIXX Pricing and Rating.
  • Resume all offers

    Recurring charges and grants applied during resumption of an offer are recorded in separate recurring events.

  • When writing off balances, immediately forfeit the balances in the wallet regardless of the Forfeiture Enabled balance template setting for balance expiration.
  • When a status change occurs, record the date and time in a custom data container field.
  • When a status object transitions to another status, set the date and time for when the next status transition will occur to a custom DATETIME field of the status object.

  Storing the date and time when the next status transition will occur in a custom MDC field applies to a subscriber, group, device, user, account, or offer.

  For a list of all actions that can be applied per object, see the discussion about status transition actions.

Status life cycle transitions that are applicable for specific offers are only applicable at the level of the purchased bundle or the purchased offer and not offers which were purchased as part of a bundle. For example, a product offer that is configured to automatically cancel on a state transition will only transition if it is purchased individually, and not as part of a bundle. However, if the same bundle is configured to cancel on a state transition, that purchased offer is canceled.

These fields are added to the REST and SubMan query responses (MtxResponseGroup, MtxResponseSubscriber, MtxResponseUser, and MtxResponseDevice) when they have values.

SubMan API and REST Calls

This query returns the possible status transition and the allowed operations for each status.