Problem Statement
Personify clients may be experiencing an issue if they are using a Personify MBR type product tied to a Subscription product in Learner Community. The problem stems from the fact that a user cannot have more than one active order at a time in the MBR type products in Personify (per CycleBegin/CycleEnd date). Many of you may have seen issues related to Learner Community being unable to create a $0 order for a product in Personify because the user already has an active order. Stated differently, the issue comes into play when the user attempts to enroll in the product again before the order CycleEndDate passes in Personify.
The most common path that we see in Learner Community is when a Learner Community Subscription product is tied to a MBR product type in Personify. In this scenario, if a user attempts to renew their Subscription in Learner Community via an enrollment code before the existing order's CycleEndDate passes, Personify will reject the order telling us that the user already has an order in the product, which will ultimately result in a customer service call.
Here is a picture that demonstrates the problem:
Solution
Good news is that we have found a way to solve this problem which should cover the vast majority of cases!
Let's consider the case above where a user is using Learner Community enrollment codes to enroll in a Subscription that is tied to an MBR type product in Personify. In this scenario, the user is preemptively redeeming a new enrollment code for a Subscription that is about to expire. Today the integration would fail because Personify would reject the order as the CycleEndDate for the existing order is in the future (remember, Personify won't allow overlapping active orders for MBR type products). To solve this problem we will do the following before we attempt to create the free order in Personify:
Search order detail records for the user using:
- LineStatus = Active
- CycleBeginDate < now
- CycleEndDate > now
- BaseTotalAmount = $0
- ProductType = MBR
- ProductCode = the product code
If we find a record, there will only be one of them. Because the existing order item is $0, we can change the CycleEndDate to be yesterday without it impacting the financials. We will also append an appropriate comment to the order detail record. Now that the CycleEndDate is set to the past, Personify will not reject the new $0 order because there are no overlapping active orders for the product.
Many thanks to the team at ASHP for helping us validate the solution. We will be working on incorporating this into an upcoming Sprint.
