Any PeopleGrove Users?

Tom Klimchak

Hi... we're going to be implementing PeopleGrove, which is an online mentoring/alumni community tool.  It looks interesting but it's basically going to be creating a secondary database of alumni data online.  We're a little concerned about the import and data update process.  It doesn't seem to store data with the level of complexity that RE does.  Has anyone else here used it?  Tried playing around with it?  Have any tips or tricks?  Thanks!

Peter Folkert

Hey Tom:


We are currently implementing PeopleGrove (PG). We went for one of the "lighter" packages that puts the onus of implementation and development on us and not PG.


I am currently building out the queries and exports in RE that we will use to bring data into PG. There are multiple types of imports in PG depending on the type of data you are sending over, so I will have multiple types of exports in RE that we will need to run each time we send data to PG. Additionally, it is not a straightforward data dump. I will most likely need to involve IT to help me transform some of the data I pull out of RE because the PG data import template calls for data to be formatted in a specific way.


As far as bringing data back from PG, this will also be a manual process. PG does have a tool that looks for new changes, but it has the potential to be cumbersome. Since we aren't live yet, my data team hasn't experienced it yet so I can't give concrete feedback. That being said, it is nice that there is a tool in PG that looks for changes to data on each record.


We are not using the PG API. Making the two systems "talk" to one another will be manual (for us, depends on how much you want to pay PG to make something for you...or have your own IT resources invest in programming). We have yet to decide on frequency for contact info updates going to PG.


We are looking to go live and market to users in the start of the new year.


Hope that helps, feel free to let me know if you have any specific questions.

Corbett Shinn

Hi Tom-We are also in the implementation process. I don't work directly with it, but happy to put you in contact with our Director of Gifts and Records who is leading the charge from the RE side. From what I understand, we also can't directly use the API and our IT department needs to be involved to do some programming to the files to move between the two systems. We are currently slowly rolling PeopleGrove out to key volunteers and it will eventually replace our current online directory.

Tom Klimchak

Thanks for the replies!  It's good to see there are a few other PeopleGrove users out there!


We're just starting the implementation process and I was struck by a few things:

• It looks like all our data will have to be manually updated in both directions.  Thank you for confirming this! If PeopleGrove takes off I could see it being an argument for more resources for my department.
• We've been told that if someone updates their information in PeopleGrove any "update" import from RE will NOT overwrite the "touched" data in PeopleGrove.  That has the potential to cause a lot of headaches.
• We're going to have to format our exports in JSON format(?).... I'm vaguely familiar with JSON but it looks like this might be different from just kicking out an excel export and converting to .CSV.
• Using a "common ID" as a primary key between the various database audiences we want to import is going to be... challenging... for us. I could see where this might be easy for some other institutions.

I'm sure I'll have more questions as we move through this :-)

Peter Folkert

Tom:


You are very much right about updates in PeopleGrove. As soon as a user creates their account and updates their information, you will not be able to overwrite the touched fields. While this could be contentious, I think it will work out for us. The theory being if a user created an account, they are now maintaining it. I guess this could cause headaches if you are collecting data in other areas and your users expect this to automatically translate to PG.


The JSON thing I am not as worried about. The import templates call for a CSV. There are a couple of fields within the CSV that they want formatted as a "JSON array." This is the one area I am going to work with IT to make sure that it is in this array format. For us...this may ultimately mean that after I pull data out of Raiser's Edge, I will have to run the data through a separate database or process (Access maybe) that "transforms" the fields that hold the array information into one single field as a part of the array.

• Sidenote: This process of transforming the data is probably going to be similar for the majors and student activities we are importing as well. I have over 250 majors from the history of our institution, some don't exist anymore as a current program. We will be translating the older majors to line up with the more contemporary ones. Same with student activities (things alums did at our institution when they were a student). For those, we have over 600 codes. A lot of them can be consolidated into groupings so that the user experience isn't degraded by having to scroll through many options.

The common ID I am struggling with. Do we use constituent ID or import ID? Occasionally we delete records (not alums...but parents or friends). I am thinking import ID would be more static and unchanging than constituent ID, but I could be wrong.

Carol Flint

I noticed your conversation from 2019 and have some questions on what you're doing currently. We are implementing PeopleGrove this spring, and I'm trying to learn if manual imports back to RE are still best or is the API working. What are you currently doing? Thanks for your advice on this?