Defunct Organizations

Gawain,

I am curious as to why you would want the account to remain active (albeit with a "defunct" status) if it has ceased operation.  I am sure you have good reasons, but with how we have used the inactive reasons, we have not found a need for that.

So how I always thought of "Inactive" was that, as you do, Inactive stands in the place of account deletion, but I also thought of Inactive as just being, well... inactive, as well.  We have 4 inactive reasons that we use (outside of the standard 1=Active and the V.14 Purge additions):  2. Defunct Organization, 3. Bad Account Record, 4. Deceased and 5. Customer Preference.

We use #3 in the situation of wanting to "delete" an account, but #s 2, 4, and 5 are used for data that we of course want to save because they have history with us though, due to circumstances will almost never truly be practical for us to reference in the future in terms of planning education, marketing and development strategies.  And #5 will likely begin to move towards the Purge and GDPR stuff, even though we are in the heart of central Indiana and our international attendance is in the single digits.

I suppose I could see a defunct organization as wanting to still be active if it JUST became defunct.  At any rate, that is how we have used them in the past.

John

I'm routinely asked to un-inactivate accounts (a lot of our security groups don't have that privilege) because some edit or update was required.  For instance, I think you can't change A1/A2 status on an account if it is inactive.  So if a customer in a household dies and you inactivate them, then the partner re-marries, you have in re-activate them to transfer the A2 status.  But I'm also concerned about certain research operations not properly pulling in inactive constituents, even though we still likely want to know information about their history (e.g. they won't show up on any lists).

Tessitura internally triggers a lot of behavior off of the name status of Deceased, and we expand on that for our standard communication suppressions, etc. so I think that is generally sufficient to flag and provide special handling for deceased constituents, outside of completely "ghosting" them.

For the A1/A2 status thing, as the more modern people are not as obsessed with continuing to be addressed as Mr. and Mrs. Jane Smith after John has died, we have just adopted the policy of removing any A1/A2 association with an individual account on any household when a patron has died.  Thus that individual constituent can still be left alone and as inactive when the other member of the household remarries, etc...

And the reporting and other stuff really has not been a significant factor for us right now, so I will leave this here for now.

Though I am also quite curious what other organizations are doing with stuff like this.  Quite frankly, with regards to a lot of these sorts of things, I basically just took control of the details of Tessitura and decided what we were going to do with a lot of them about 5 years ago and no one has ever fought me on them.  So I have no idea whether I am doing them optimally or just no one has cared enough to complain.  But our users seem to be happy enough with the results, so I guess all's well as they say.

Gawain Lavers said:

I got a request to inactivate a foundation a while ago because the foundation in question had ceased operation.

Dating back to pre-Tessitura days, we set these to Inactive, with inactive reason = "Obsolete/Historical Account".

Bonus puzzle: I'm unable to do a mass update of inactive_reason in SSMS: it just hangs.  I don't see an obvious reason for this in, say TG_CUSTOMER_UPDATE, and it could always be some issue with a script in LP_CUSTOMER_RANK getting hung up on an inactive account, but has anyone else seen issues with this?