Taking people off the system (if a member passes away, moves out of area, etc)

From AUKC Helpsite
Jump to navigation Jump to search

Charitylog has several different features that cover this.

The Active field[edit | edit source]

Screen Shot 2018-10-11 at 13.41.26.png


Everybody has a master "Active" field. This field basically means "is this person available on the system or not". If you set this field to "no";

  • people won't come up in search results any more (because almost all searches default to "active people only"
  • people will usually be excluded from data extractions and mail merges
  • occasionally they may be excluded from some reports (but this is rare)


"Deceased?" field[edit | edit source]

Screen Shot 2018-10-11 at 13.51.46.png


There is also a "Deceased?" field which simply marks people as deceased. If you set this field to "Yes";

  • people come up in search results with a "D" next to their name

If someone passes away, it's probably appropriate to mark them as "Deceased". However, it may not be appropriate to set their "Active" field to "No". I recommend that people remain Active on the system unless a) they have requested to be removed from the system, or b) they are being removed for GDPR reasons - if we haven't heard from them for 5 years, for example.

Annoyingly, if you mark someone as Deceased, Charitylog automatically leads you on to make them Inactive, via this screen:

Screen Shot 2018-10-11 at 15.28.10.png

The field ringed in blue is a bit dangerous. It automatically sets itself to "No" (i.e. "make this person Inactive"), so if you do not want the deceased Member to be made Inactive, you will need to set this back to "Yes" - but for AUKC, generally we do want people to be made Inactive when they pass away, so it can be left as "No".

There then follows a section about Project Termination. IGNORE THIS.*


What about people who move away?[edit | edit source]

If a Member moves away, it may be appropriate to mark them as Inactive, but not always.

Charitylog doesn't really have an inbuilt feature that includes some sort of status that "this person has moved away". I would argue that this is correct. Someone moving away doesn't change anything about them apart from their location, so obviously their address should change, but I don't think there's necessarily any need to do anything else as far as the person themselves is concerned.

There is a field to mark whether the address is "known good". This field is used to mark if there is a problem with someone's address, but the new address is not known yet. This happens when mail is returned as "not at this address" etc - there is clearly an issue with the address, but we don't know if it's because the client has moved, or perhaps passed away, or the address is wrong. Whatever the issue turns out to be, use this field to mark the address, and that person will be excluded from mailings until we are able to confirm a new address or remove them from the system.

Address known good.gif


However, someone moving away is a valid reason for a piece of work to come to an end. Therefore, I have added an option on the Simple Outcomes for Referrals that covers this. If someone's Referrals are going to be closed because they have moved away, this can be logged as the reason.

Screen Shot 2018-10-11 at 15.23.50.png



Misuse of the Active field[edit | edit source]

Charitylog customers often use the "Active" field at the wrong time.


If someone's Referral has finished[edit | edit source]

When a Referral finishes, people sometimes mark the member as Inactive. This is wrong. The appropriate thing is to close the Referral. This can be done from the Outcome screen for that Referral.

Whether or not someone has an open Referral is really important. This is how we report on service loads and case loads, not by looking at the Active field.

  • "Number of clients on the books" = number of members who have an open Referral.
  • "Number of clients who moved through the service in quarter 1" = number of members who had a Referral open at any point during that time period
  • "Number of clients new to the service last month" = number of members whose first ever Referral was opened during the last month

...and so on. All these reports can be done based on the Referral data. The "Active?" field doesn't need to come into it.


*Project Termination - read on at your own risk[edit | edit source]

Project Termination relates to the client-project record.

This is a structural bit of Charitylog that you don't really need to know about, but I feel I should explain it for anyone that wants to know. Be warned, this is going to get a bit confusing. There is no shame in ignoring this bit :)

Referrals, as you know, are pieces of work on the system. When you create a Referral, you actually create the Referral itself and also the first Contact in that Referral. So far so good...

But a client-project record is also created. This is a record that logs the fact that the Member is involved with a Project. For a Member to have Referrals in a Project, they also need to have a client-project record. This is difficult to understand because the client-project record doesn't relate to anything in the real world. A Member relates to a real person; a Referral relates to a piece of work... but a client-project record doesn't really relate to anything. If anything, it almost relates to involvement with Projects, i.e. if a Member is linked to a Project by a client-project record, they are "on the books" of that Project. When you terminate a Member in a Project, you take them "off the books". Except for one important thing: There can only ever be one Client-Project Record per Member/Project combination.

This means that using the Client-Project Records to get an idea of "who's on the books" is fundamentally flawed, because people can never move off the books and then back on again. Once the client-project record is terminated, it can't be automatically opened again, it has to be done manually, meaning:

  1. people who have had a Client-Project Record terminated will never appear "on the books" again unless the record is manually un-terminated if they return
  2. people who have had a Client-Project Record manually un-terminated will appear to have been "on the books" continuously since they first got referred

So the reports will be wrong in either direction.

For this reason, I always hide the existence of the Client-Project record whenever possible. I have been doing this for about four years with Charitylog customers and nobody has ever noticed. More to the point, no customer has ever asked for a report that required the use of Client-Project Records. Unfortunately, sometimes the existence of client-project records can't be hidden, such as on the screen that appears after you mark a Member as being Deceased.

I have requested the capability to hide all of this completely but Charitylog aren't willing to do it, so for now, I just have to train people in the avoidance of Client-Project Records, and occasionally do a bit of tidying up behind the scenes.

Charitylog's own page on Client-Project Terminations is here.