Hello,
First, we are self-hosted and use TNEW for our website.
I'm struggling to figure out the correct series of events to be able to be able to proof events on the website without making them visible to the public. Here's my plan (which worked in the test system), but I'm wondering what I'm missing as to why it's not the best idea...
Where are the pitfalls or major flaws in my logic here?
[Side note: Many moons ago, when we were first converting to Tessitura, our installer used the phrase "inherently wrong" as in: "I don't quite know what's wrong with that plan, but it just feels inherently wrong." I'm simply trying to avoid anything being "inherently wrong"... ]
Thanks as always for your wisdom!
You can use TR_WEB_SOURCE_NO and and a source code to shift the MOS to your testing MOS without using Ranks. That way you can have your team test it off the one link.
Thanks Heath. Is there a down-side to using Rank, if that ranking is only applied to ONE patron record?
I too would advocate using a promo code-based MOS shift, but I think for us this only decreases the "blast radius" compared to the ranking-based solution since we already use promo codes for presales -- so we just create the promo code with a start date for when we want to begin testing, and then it "goes live" when the promo code is released to the public presale cohort. If you don't do anything like that already, then I can't see how the ranking-based MOS shift is any more inherently wrong than the promo code-based MOS shift... If I were to suggest what solution would be "inherently right", it would be proofing in the test system, but Tessitura doesn't really have a concept of "deploying to Live from Test", so I think we may be out of luck there.