Home > Aria Crescendo Documentation > User Self-service Best Practices

User Self-service Best Practices


User self-service (USS) provides your customers with the tools to manage their accounts. In your user self-service (USS) application, your customers can take the actions listed below on their account. Your customer support representatives can also complete actions such as the following in your CRM (customer relationship management) application:

  • update contact information;
  • update payment information;
  • update, switch, add, or cancel plans (products);
  • place orders for inventory items;
  • make a one-time payment;
  • view statement, transaction, and order histories;
  • reset a forgotten password.

Updates to your customers' accounts take place immediately and you are informed of the changes by your chosen event notifications.


To implement the USS use cases listed below, you must first take these actions:

  1. Whitelist your IP addresses.
  2. Obtain your client number and authorization key.

Important Notes

General Notes

Queuing Rate Schedule Changes

If you have set up future rate schedule changes, keep the below points in mind. See the use cases below for sample scenarios involving rate schedule changes.

  • Aria will assign a plan's default rate schedule to a plan subscription unless you specify a different rate schedule.
  • If rate schedule 1 (RS1) expires on 30 September 2020 and rate schedule 2 (RS2) goes into effect on 1 October 2020, pre-existing accounts with RS1 will not get switched over to RS2 on 1 October 2020. Pre-existing accounts will continue to be charged RS1. As of 1 October 2020, you can assign RS2 to customers who add plans associated with RS2.
  • If rate schedule 1 (RS1) switches from $25 to $30 on 1 October 2020, pre-existing accounts with RS1 will be charged $30 as of 1 October 2020. As of 1 October 2020, customers who add plans associated with RS1 will be charged $30.
  • You can assign a rate schedule only if it is available (in effect or not expired) on the plan activation date.

    Example: on 30 September 2020, you cannot assign a plan with activation on 30 September 2020 or 15 October 2020 with a rate schedule that will be in effect on 15 October 2020. Use the Schedule Future Rate Change feature if you want to assign a rate schedule that will be in effect at a later date.
  • If you add a plan with an immediate or a retroactive start date, then the rate that is active at the time of plan addition will be applied to the assigned plan.

     Example: You have RS1 that will change from $40 to $50 on 12 April 2020:

    • If you add a plan on 10 April 2020 with a retroactive start date of 1 April 2020 and assign RS1, then the customer will be charged $40 for the first month.
    •  If you add a plan on 16 April 2020, with a retroactive start date of 13 April 2020 and assign RS1, then the customer will be charged $50 for the first month. 
  • If you assign a plan with a future start date, then the rate that is active on the plan activation date will be used.

    Example: You have RS1 that is set to change from $40 to $45 on 14 October 2020. If you add a plan on 10 October 2020 with an activation date of 10 November 2020 and you assign RS1, the customer will be charged the new rate of $45 on 10 November 2020.

Best Practices

The best practices to follow when designing your USS application are as follows:

  • Ensure that the information your customers can see and actions they can take meet your business requirements.

    • If your services are offered only at the supplemental plan level and you have a master plan that is assigned to all new customers by default, then you should not show your master plan to customers.
    • If you do not offer inventory items for customers to order, you should not show an ordering section in your application.
    • Allow customers to select only the payment methods that your company accepts.
  • Provide customers with the ability to perform the required actions for managing their accounts.

    Example: Provide a text box in which customers can enter the number of units of a plan to which they want to subscribe.
  • After a customer logs in, use the validate_session_m API call at every page load to determine the validity of the session and the customer with which the session is associated.
  • In every API call used to add, update, switch, or cancel plans, set the <do_write> field to false before displaying a confirmation page to the customer. This will prevent the plan change from going into effect before the customer confirms the requested change. After the customer confirms the request, you can call the applicable API again with the <do_write> field set to true.
  • Establish company-wide rules that apply to your billing practices and when exceptions to those rules are allowed. That is because some arguments that you pass into APIs may override your company-wide rules (that you specified in your client parameters). In addition, it is important to be aware of what actions Aria will or will not take because of your company-wide rules.

    • The proration rule that you pass into an API will match or override your client parameters for proration.
    • A bill date reset rule that you pass into an API will match or override your client parameters for resetting bill dates.
    • Bill dates will or will not be reset when accounts or plans change from a non-billable to a billable status depending of your client parameters for resetting bill dates.
  • Include a Terms and Conditions link from which customers can access information about the general terms or the agreement under which they may use your application.

Use Cases

Click on any of the links below to see instructions for working with APIs to complete a few common USS uses cases:


Note: The sample calls shown in the USS uses cases contain a few key fields needed to successfully complete the specified action. You may choose to pass in additional values based on your business requirements.

Examples: You may want to:

Please see the documentation for the API mentioned in each use case for detailed information about additional available fields.


Last modified


This page has no custom tags.


This page has no classifications.