Page Comparison

With this release, the interworks.cloud platform features the full range of Dropbox upgrades along the path:
Standard→Business→Advanced→Business Plus

Subscriptions can also be upgraded to the same plan (e.g. Business→Business) which contains any add-on of:

• Extended Version History

• Data Governance

• Premium Support

• Replay

With this release, API V3 has been updated to match the following behavior in BSS: When selecting to cancel a subscription on a specific date, the specified date must be a past date within the current billing cycle, the current date, or the renewal date. A future date cannot be specified.

Specifically, when a POST /api/subscriptions/{subscriptionId}/cancelspecificdate request date under specificDate which does not meet these requirements, the system returns the following error message:
Cancellation date cannot be after the current date: {currentDate}.

For the purpose of aligning the BSS and Storefront in terms of user experience, it has been decided that any paid subscriptions must always have a corresponding order, regardless of whether they originate from the Storefront or the BSS. In an upcoming release, paid subscriptions will only be created by placing an order and only trial subscriptions will be created using the current method of creating subscriptions. The API will also be updated to match this functionality, to align with the interface. Please note that on June 15th, the following API V2.2 endpoints will be deprecated:

• POST /api/Subscriptions

• POST /api/Subscriptions/invoiced

How to Create a Paid Subscription by Executing an Order

To create a paid subscription without the use of these endpoints, use the following API V3 endpoints:

• POST /api/orders - To create an order

• POST /api/orders/{orderId}/items - To add items to the order

• POST /api/orders/{orderId}/execute - To execute the order

• GET /api/orders/{orderId}/execute/status - To retrieve the status of the order

A paid subscription based on the order will be created when the status of the order is Executed.

As part of our ongoing commitment to improve your experience with our public API V.3, we are introducing a significant enhancement related to custom fields for subscription management, per Service Manager instance. We understand that managing custom fields efficiently is crucial for your operations, and we’ve taken steps to address some common pain points. Here is the key update:

Unique Identification of subscriptions per Service Manager instance with the ‘ApiField’ and the 'instance ID' custom fields:

Custom fields are created per Service Manager instance, which can lead to ambiguity. In scenarios where an organization has more than one instance, all identical custom fields of subscriptions across different instances share the same ‘Code for Provisioning System’. Also, since this custom field is editable by BSS users, and we have observed instances where customers have modified the name themselves, so we needed to ensure a consistent and unique identification for each subscription per instance. To address this, we have introduced two new identification API fields, namely, the instanceID and the ApiField:

1. The instanceID: This additional identification field allows you to differentiate custom fields across Service Manager instances effectively (for example between an EU instance and a USA instance), since it contains the actual identification number of each instance.

2. The ApiField: This additional identification field allows you to retrieve the “Code for Provisioning System” custom field value of a subscription. Essentially, this field contains the code for the provisioning system for each subscription.

You can utilize both the aforementioned API fields by executing the following API Call:

GET api/organization/subscriptions/customfields

You can also find the APIField and the Instance ID values within the following endpoints:

#1: api/organization/accounts/customfields
#2: api/organization/assets/customfields
#3: api/organization/files/customfields
#4: api/organization/pricelists/customfields
#5: api/organization/contacts/customfields
#6: api/organization/orders/customfields
#7: api/organization/invoices/customfields
#8: api/organization/leads/customfields
#9: api/organization/pricelists/customfields
#10: api/organization/products/customfields

The following issue was addressed, with fixes applied where necessary:

1. Retry Tool of Migrator - Handling Invalid Error-Messages: An issue was addressed where during the migration, an invalid message from Microsoft caused processing errors. The message was moved to the retry queue while subsequent retries generated messages with empty migration details. This generation of error messages was caused by a typo in the verification mechanism which triggered further reprocessing, while no traces appeared in the activity log. We have corrected the code to prevent this issue from happening in the future.