Audit Church Affiliation and Denomination

Options
Bob Wiebe
Bob Wiebe ✭
Ancient Membership Facilitator 1 Photogenic
in Blackbaud Raiser's Edge NXT®: General Discussion
I would like to run a data audit ensuring that the correct denomination has been used to correspond with the church affiliation field on Bio 2 for individuals.  I could create a query which groups together all the persons who have a given denomination code and whose church affiliation is other than the 330 churches in that denomination.  This would highlight denomination codess which need changing.  I would rather not have to enter the 330 churches, and am trying to imagine a way to do this comparison more efficiently.  If the church affiliation was the constituent number instead of the church name, or if there is a number hiding in the field realted to church affiliation, this might be a quicker job.  Thanks for your thoughts.
Tagged:

Comments

  • Matt Page
    Matt Page ✭
    Tenth Anniversary Facilitator 2 Photogenic
    Hi Bob,


    I must admit I'm not entirely sure what you're asking, but it sounds like you might need to create an attribute for the denomination code. And if you're wanting to have the names of the 330 churches in an RE field without manually entering them you might like to look at IMPORT. There's the option to create new entries in a table which might prove helpful.


    Matt
  • Ryan Hyde
    Ryan Hyde ✭
    Tenth Anniversary Facilitator 3 Name Dropper Photogenic
    I think we'll need some more clarification on how exactly your data is set up.


    I imagine "denomination" is kept within the Religion field in Bio 2. What's not clear is how you're storying church affiliation. Is this kept as a relationship? And if so, is the church itself saved as a constituent record?


    Or is the affiliation saved as an attribute with a Description field set to "constituent name" where you then attach the church that the individual is associated with? 


    If it's the former (relationship), then you could tighten up how you encode data to make this audit very simple - but of course this will take some work on the front end. Thankfully, you'll only have to do this once.


    The best way to set this information up that I can think of right now, or at least the best way to facilitate the kind of audit you're trying to do, is to hijack the "Industry" field in Org 2 to match the denomination list available in Bio 2 "Religion." You can even make "Industry" a required field. Of course I'm sure you also have non-church orgs in your database, so you'll want an "industry" of "no denomination" if you want to do that.


    Then your query will look like this:


    - Constituent is Individual (or start with an Individual query, either way)

    - Religion =/= [denomination1]

    - (Relationship > Organizations > Constituency > Constituentcy Code = Church (I assume that's how that's coded in your database)

    - Relationship > Organizations > Industry = [denomination1])


    (note the parentheses on the last two lines - that's important for individuals who might have relationships with both a church and a non-church organization)


    That should be it. Then you can use your query to effect a global change so that all individual Religion fields are equal to their affiliated church's Industry field. 


    Caveat: I don't have data like this at all in my database (we're an animal welfare org) but I think this will all work. You should absolutely test this out on some example records to see if the concept works before you commit to doing the work. 


    Note: If this does work and you want to update this info for all your churches, I would highly recommend doing this via an import. Much easier to manipulate this kind of data in Excel and then populate the Industry fields during an import.




     
  • Bob Wiebe
    Bob Wiebe ✭
    Ancient Membership Facilitator 1 Photogenic
    Thanks for the responses.  Denomination is a field in Bio 2 which pulls on a table of denominations (actually filed under "Ethnicities" in Configuration).  Church Affiliation is also a field in Bio 2 which pulls on a table of church names (filed under "Religions" in Configuration).  Neither of these fields allows populating a "one of" list like one can with Constituent ID. 

    When I build my query I hold one variable constant, like denominatiion, and further screen by the churches in that denomination.  This is time consuming because I have to manually select each of 300 congregations from the drop down list.

    I think what I will do is export a list of constituents who are coded with the denomination in question and include their church affiliation, then use V lookup against a list of the churches that belong with the denomination to identify any churches that were coded with the denomination that should not have been.

    Sorry if this is confusing!
  • Ryan Hyde
    Ryan Hyde ✭
    Tenth Anniversary Facilitator 3 Name Dropper Photogenic
    Oof, yeah, having the affiliated church just in a dropdown menu and not linked in some way to an actual constituent record makes this all very difficult. Doing your work in Excel may indeed be your best bet.


    I would recommend rethinking how you store this data. I think keeping your churches all as organization constituent records and saving their denomination either in the way I mentioned or as an attribute with a dropdown description field would make your life a lot easier, once you get all the records created and coded properly. You can globally add the relationship based on the current dropdown menu you have, and then you'll be able to do your audit in the way I described.
  • Matt Page
    Matt Page ✭
    Tenth Anniversary Facilitator 2 Photogenic
    Ryan's suggestion sounds good to me, but if there's a problem with that there are two other options:


    1. You could set it up as an attribute. You'll have to put it as a "Comment" rather than a "Description" though to use the "one of" functionality.


    2. You could just manually do a query just with the 330 entered as a one off and then save this somewhere where no one will change it (and save a copy!). Then you can use this query inside other queries by going to "Query Options", "Record Processing" and choosing it in "Select from, Query". A little time consuming initially but might be quicker/more convenient than re-configuring how you currently use the fields. Just make sure you've protecting it from overwriting it whilst saving.


    Matt
  • Nicole S
    Nicole S ✭
    Ancient Membership Facilitator 3 Name Dropper Photogenic
    I think that Matthew has a good suggestion.


    I often will create queries or query lists for groups of one off records instead of changing how we enter the information. I found that in the past every single time someone wanted to group a few records at one org, they were adding an attribute or constituent code.


    Most of the time this group was never used again or wasn't relevant to anyone else or oddly specific or only a portion of the whole group. Basically, a person would be looking though reports or RE and say "hey, I'd really like to pull more info onthis, this this, and that record even though they don't have much in common." Usually by highlighting a printed report. Then they'd make some kind of coding, look at a report or two, find nothing interesting, and never think about that group of records again.


    In the end there were dozens of constituents codes (that meant nothing) and even more atributes (and the attributes acan't event be fully deleted globally). It became overwhelming for people to work with.


    By cleaning up the old useless coding and working from queries/lists when the group was just a one off, it removed a lot of clutter from the database and actually prompted people to think a little bit more about what these records had in common. Plus, by keeping the queries, if we ever did look at the list more than once, it was easy enough to add relevant, thoughtful, planned out coding down the road.

Categories