Review `Clear subscription` mechanizer function
Summary
Force reassociation is the third most used mechanizer function and supports for multiple use cases.
This function is used to unlink a namespace and subscription, which can be necessary for multiple reasons. Many times Clear subscription gets used when an action errors out and the subscription needs to be put in a certain state in order for the action to succeed. In this vein, it is often the function used in combination with force reassociation.
The goal of this issue is:
- to review the use cases that this function is supporting and getting to the root of why these use cases exist
- next steps: once we have a good understanding of the use cases, we will address each use case separately and form a plan to either reduce mechanizer usage for the use case, or migrate the mechanizer function to customersdot
Outside the scope of this issue, but iterating towards:
- solve for the use cases with reasonable product or process changes, that does not increase the existing burden of effort for any internal team
- deprecate this mechanizer function
Use cases
1. Resolve the error from Force reassociation function usage
2. Deprovision trial or plan
Analysis of root problem for each use case
Ask the following questions for each use case:
- why does the use case exist?
- are there any workarounds?
- is the function addressing a bug or a missing feature?
1. Resolve the error from Force reassociation function usage
Why does the use case exist?
Sometimes, when trying to use the function on a namespace, the action results in the following error:
unable to associate the subscription as the destination namespace is already associated with a subscription
The error indicates that an order is currently attached to the namespace and an association is not possible. The Clear association function detaches the order and makes association with a new order possible.
Are there any workarounds?
No, because the namespace is in a state that makes it impossible for the customer to self-serve any changes.
Is the function addressing a bug or a missing feature?
The error may be a result of previous manual intervention that has placed the namespace in this "abnormal" state. Less manual intervention could lead to less reliance on this function. We know that there are many good reasons for manual intervention and those uses should be addressed in order to see a reduction of this use case.
2. Deprovision trial or plan
Why does the use case exist?
For many reasons a trial or plan reaches its end date, but never gets deprovisioned and unlinked from the namespace. In this case, the namespace cannot link with any new orders because it is still attached to the expired trial/plan.
Are there any workarounds?
No, because the namespace is in a state that makes it impossible for the customer to self-serve any changes.
Is the function addressing a bug or a missing feature?
We should investigate why trials and plans are not deprovisioned properly. Proper deprovisioning will eliminate the need for this function in this use case.