Membership audit log, required fields
Posted: Tue Aug 25, 2020 7:23 pm
Hi,
We're working on cleaning up PowerChurch data. With multiple people working in the database over the years, and not all of them highly skilled at data management, it's quite a mess. Our big push has been to deactivate people who are no longer involved, which we mostly do with the Personal Profiles "Status" field. I thought we were making great progress until I discovered that there are over 100 people who have no Status at all! So the first question is whether there is any way to flag certain fields as Required, so that it is not possible to create a record without filling in the field?
I'd actually like to see the Required Fields idea taken one step further, where one could build wizards for various events and the fields that get updated. For example, if someone joins, we should change their status from visitor to member, note down the date they joined, make sure we know their baptism status and date if available, note whether they joined by transfer or affirmation of faith, etc. And of course an audit log of who made this change and when.
Re. audit logs: we often need to figure out who made changes when and why. We're currently on PC 11.55. After I resurrected an old thread here, Neil Zampella suggested that I try the audit log feature in PowerChurch 12. I've downloaded the 12.2 demo. I've been able to confirm that it tracks adds and deletes of both Family and Personal records (even though it only appears under the Personal Profiles menu). It logs the date, time, partial user name, and a brief note about the add or delete. However it does not track data changes e.g. an address or Status update, which would ideally be displayed in a tab under the Family and Personal records. And there is no way to add a reason for the change, e.g. "joined church" or "moved away".
I know that required fields and field-level auditing are a lot to ask (I have actually developed an insurance database that does both), but those features could really help in creating consistent data in the first place, and in figuring out why certain data looks like it does.
If there is anything I'm missing, let me know!
Thanks,
Mark Berry
We're working on cleaning up PowerChurch data. With multiple people working in the database over the years, and not all of them highly skilled at data management, it's quite a mess. Our big push has been to deactivate people who are no longer involved, which we mostly do with the Personal Profiles "Status" field. I thought we were making great progress until I discovered that there are over 100 people who have no Status at all! So the first question is whether there is any way to flag certain fields as Required, so that it is not possible to create a record without filling in the field?
I'd actually like to see the Required Fields idea taken one step further, where one could build wizards for various events and the fields that get updated. For example, if someone joins, we should change their status from visitor to member, note down the date they joined, make sure we know their baptism status and date if available, note whether they joined by transfer or affirmation of faith, etc. And of course an audit log of who made this change and when.
Re. audit logs: we often need to figure out who made changes when and why. We're currently on PC 11.55. After I resurrected an old thread here, Neil Zampella suggested that I try the audit log feature in PowerChurch 12. I've downloaded the 12.2 demo. I've been able to confirm that it tracks adds and deletes of both Family and Personal records (even though it only appears under the Personal Profiles menu). It logs the date, time, partial user name, and a brief note about the add or delete. However it does not track data changes e.g. an address or Status update, which would ideally be displayed in a tab under the Family and Personal records. And there is no way to add a reason for the change, e.g. "joined church" or "moved away".
I know that required fields and field-level auditing are a lot to ask (I have actually developed an insurance database that does both), but those features could really help in creating consistent data in the first place, and in figuring out why certain data looks like it does.
If there is anything I'm missing, let me know!
Thanks,
Mark Berry