sonamedic: Promotion Codes That Control Access
Health insurers and corporate clients hand out codes, and every code unlocks something different. What it unlocks and when it is used up is a rule inside the system.
Services Used
The situation
sonamedic runs an application for mindfulness and relaxation. Access is not only sold one seat at a time but through promotion codes: health insurers, corporate clients and partners hand codes on to their people. Every code unlocks something different, for a different length of time and in different target systems. On top of that, sign-in and user data live in two separate systems. I was responsible for this part, from the interface through to the administration screens.
The solution
At sonamedic a promotion code is a small set of rules. Eight kinds of duration, from hours to years, plus a fixed expiry date. What it unlocks is set separately for each of the three target systems. Added to that are a validity window and a seat allowance. On redemption the application checks window, allowance and target in that order, and once eighty percent of the seats are taken an email goes out to whoever issued the code, so a corporate client can top up before the first people run into an exhausted allowance. Error messages carry the user's language with them instead of guessing it from context.
The administration side is a screen where sales create single-use codes in batches, by group and prefix, and download them as a list. Group and prefix are both the way to navigate the stock and the unit in which codes are deleted again. The rules sit in the form itself: which field is mandatory depends on the kind of code and the target system chosen, validated by the same rules that apply on the server.
Sign-in and the platform database are two systems for the same people. Four separate functions hold them together: one creates the database user after registration, one keeps both records in sync, one sets permissions as claims on the token, triggered by a message rather than a direct call. A fourth finds inactive users and calls itself page by page, because a single run would otherwise exceed the platform's time limit. In the administration screens both records sit side by side in two tabs, so that records drifting apart is visible rather than something to go looking for.
The result
Sales create and hand out codes themselves, without a developer having to do anything for it. What a code unlocks, and when it is used up, is a rule the system can check rather than something agreed in a conversation.